@Peter this is a genuinely good question and you're clearly already thinking about it at the right level, so let me be straight with you rather than oversell.
The MultiNav Pro+ is built on the STM32WB07, and that chip does support multiple simultaneous central connections — but you're right that the piconet constraints are real and they compound hard at long range. The firmware repo is open source (github.com/RFOXiA/MultiNav-Pro-Long-Range-BLE-Module-Firmware-STM32WB07) so you're not flying blind — you can actually see what's exposed and tune at the HCI level rather than praying the manufacturer left you enough rope. That's the meaningful difference versus the black-box modules you've been burned by.
On your specific concern about connection interval management at 30km+: you're not wrong that you'll need to stretch intervals out to give retransmit windows breathing room at those propagation distances, and yes, that does start to bite when you're trying to service 6-8 peripherals from a single central. The honest answer is that a true 8-node simultaneous connected star at 30km is going to require careful CE length and supervision timeout tuning, and you'll probably end up with lower effective throughput per link than you'd get at shorter range — but if your data rate requirements per node are modest (telemetry, sensor readings, commands rather than streaming), it's workable.
The broadcaster/observer thought isn't crazy though — you could get bidirectionality with a hybrid approach, using extended advertising with scan response for the bulk of your downlink data and only maintaining connected mode for the nodes that genuinely need acknowledged uplink. Worth prototyping both topologies before committing to the full deployment layout. What's the actual data pattern you're dealing with — periodic sensor bursts, or do you need low-latency command-response?
