@Peter Adkins yeah this is a real concern and you're right to think about it before you're debugging a flaky fix rate in the field.
The good news is that L1 GNSS (1575.42 MHz) and 2.4GHz BLE are far enough apart that fundamental-to-fundamental interference isn't usually the problem — it's exactly what you flagged, the harmonics and broadband noise floor from the BLE PA that can creep into the GNSS LNA front-end and kill sensitivity. The GNSS receiver is trying to pull signals out at around -130 dBm, so even a few dB of added noise floor from a nearby switching PA can noticeably hurt your fix rate or TTFF, especially in marginal signal conditions like urban canyon or indoor-adjacent deployments.
Practically speaking, the things that actually help in layout: physical separation obviously, but more importantly keeping a ground plane pour between the two RF sections and routing any shared power rail through proper LC filtering so you're not coupling noise through the supply. If you're actively transmitting BLE at high power while trying to acquire a cold GNSS fix, that's probably your worst case — so if your application allows it, staggering the BLE TX bursts during initial acquisition can help. Antenna placement matters a lot too; if both antennas are on the same edge of the board pointing the same direction you'll get more coupling than if you can get some angular separation.
I haven't seen anyone report a hard desensitization failure with this specific module combo in the hub yet, but if you're running the full Developer Bundle stack I'd be curious what your ground plane situation looks like on the carrier board — that's usually where these things either get fixed or get worse.
