@Kevin yeah this is exactly the right set of questions to be asking before you commit to a solar+supercap deployment — power budget mistakes at that stage are painful to fix in the field.
I'll be honest with you: I don't have the specific measured current numbers in front of me right now, and I'd rather point you to where you'll actually get accurate data than throw out figures I'm not confident in. The firmware repo is public on GitHub (github.com/RFOXiA/MultiNav-Pro-Long-Range-BLE-Module-Firmware-STM32WB07) and since the module is built on the STM32WB07, you can cross-reference ST's datasheet for the core's sleep/wake specs — that chip has proper low-power modes and the wake latency is generally fast enough for periodic sensor reporting use cases, but how much the external PA and any always-on peripherals add on top is the number you actually need, and that's module-specific.
On the TX power question — the STM32WB series does support programmable TX power through the BLE stack, so in principle dialing back from max for a 500m-1km link should be totally doable and would make a meaningful difference to your average current. Whether that's exposed cleanly in the current firmware or needs a tweak is worth confirming directly with Moamen through the Dev Hub — he's the one who'll know exactly what the firmware exposes and what's in the pipeline. For your range requirement you're leaving a massive headroom buffer compared to what the module is capable of, so you have a lot of room to trade power for link budget.
Your concern about claimed sleep current vs reality is completely valid and honestly the only way to know for your specific board revision and firmware version is to bench it yourself with a decent current monitor — if you end up doing that, please post the numbers here because that kind of real-world data is genuinely useful for everyone planning similar deployments.
