ShortTimeNoSee I feel like there's a great potential middle ground in gating this behind a toggle in Developer Options.
That approach would reduce pressure on pre-release testing, but the release-to-release code maintenance load for the developers for this approach might not be much less than the load for integrating it as a regular feature. A developer would likely still need to handle and review rebasing.
ShortTimeNoSee Some new system property (like persist.bluetooth.disable_strict_l2cap or something), in the libbluetooth C++ code wrap the blocking validation logic in a check for this property. If the prop is true, it skips the wait/block. Then expose a simple switch in the Dev Options UI to flip that property.
It is plausible -- though not certain -- that a pull request along these lines would be reviewed. Given the ongoing turmoil in Google's AOSP effort, and various pre-existing priority projects related to security and privacy, I suspect the likelihood that a GrapheneOS developer might take this on as a personal project in the medium term (say, one year) is very low.
Also, it might not be the case that the GrapheneOS team would choose to ship code that would encourage users to enable developer options.
Please note that I do not speak for the GrapheneOS project.