From my research to write the post, it looks like: - the HFP standard was developed mainly for taking calls in a car. It seems like taking calls is still the main use case up to the latest version 1.9,

- macOS switches to HFP whenever the bluetooth headset is in use for both input and output. Interestingly, using the bluetooth mic and macbook speaker doesn't activate the HFP,

- bluetooth in general (not just HFP) seems to be designed to work under the constraint of tech from 20 years ago. Small bandwidths, small batteries, and small computational power,

- there are very nice codecs like Opus that are not used even though they've been working for over a decade.

From there I think the main problem is: - macOS should not assume you're in a call just because you're using the mic. There are a few scenarios where that's not the case and you might not care about low latency,

- better existing codecs should be used, but aren't for some reason,

- bluetooth specs should update the constraint they have to work under.