@Jessica Chan yeah this is actually a really clean use case for the MultiNav Pro+ — beacon/broadcaster mode is totally valid and you're not leaving much on the table at all.
On the coded PHY question: yes, coded PHY absolutely applies to advertising packets in BLE 5.x, it's not just a connected-mode thing. Extended advertising (the BLE 5.0 adv sets you mentioned) is specifically what unlocks coded PHY on the advertising channels, so S8 coding is available for broadcast. The STM32WB07 on this module supports extended advertising, so you're good there — you get the full range benefit without needing a connection. That's the answer to your spec doc confusion: legacy advertising (pre-5.0) is limited to 1M PHY, extended advertising is where coded PHY becomes available for broadcasters.
On the practical range question — connected mode vs. advertising — the RF front-end behavior is essentially the same. The PA and LNA are doing their thing regardless of mode, so the link budget doesn't change dramatically. The real difference is that in connected mode you have acknowledgements and retransmission, which gives you reliability, whereas in broadcast you're fire-and-forget. At range, that matters more than people expect because you'll see some packet loss on the receiver side. With solar+supercap power you could afford to send each telemetry packet 2-3 times with a short gap between, which essentially gives you probabilistic reliability without needing a connection at all.
For advertising interval — I'd suggest starting around 1-2 seconds for your use case. The receiver side doesn't really struggle with fast-interval packets at range in my experience, but slower intervals are friendlier to the scanner's duty cycle if you're trying to run the receiver lean too. If your telemetry update rate doesn't need to be faster than every few seconds anyway, 1s interval is a nice middle ground. The firmware repo on GitHub should give you a reasonable starting point to work from.
