What's the limitation? My wild-ass guess would be that rx and tx have to be on the same radio frequency, so you can't do full duplex without packet collisions.
Some sort of hardware limitation preventing two protocols(profiles) going through CODEC or something. “Back/return channel” features are emerging to encapsulate profile over profile so it might change in the future
It's that the handset profile which allows two way audio but only with crappy phone style codecs is different from the audio profile that only has one direction for an audio stream but has decent audio quality.
What I don't get is that why the H/W companies don't just solve this by including a 2nd Bluetooth chip. Give up on running duplex, run high quality audio out to the headphones, and the mic as a separate device using whatever is best there.
And beats (at least my studio 3s) on Mac/iOS/Android.
If your going to do wireless on windows, either get a separate mic, use a corded headset, or a headset with a USB-wireless adapter unless you want it sounding like a tin can.
You could just stuff two headsets into one same headphone, sharing only speaker output and power. Battery life isn’t a problem, a random BL-5C from parts bin should work just fine.
I have a new laptop running Arch, and Bluetooth headphones which nominally can act as a headset as well, but I actively disabled that functionality under Windows, because if something tried to use the atrocious-quality headset microphone, the high-quality headphones output would silently (literally!) not work, and only the low-quality headset audio output would work.
The headset modes haven’t appeared under Linux at all, which happens to suit me just fine, so I haven’t investigated the lack. A couple of times I’ve had issues with connecting at the BlueZ level, but putting the laptop to sleep and waking it up again has resolved it. (Just restarting bluetoothd doesn’t help.)
I was running PulseAudio for a few weeks, then I switched to PipeWire. I no longer get the Bluetooth indicator on it in waybar, but other than that the switch was fairly uneventful. One point is an improvement: it now seems to remember which devices I like to use, so that when I plug in my Yeti microphone it doesn’t switch audio output to it (it has a 3.5mm monitor port and can feed audio from the computer through that too), which it had always done under PulseAudio and I hadn’t yet gone to the trouble of figuring out how to stop it from doing that. One point in the Bluetooth device handling is potentially a slight regression: when silence should be being fed through the connection, I observe extremely quiet whine which I didn’t under PulseAudio. Not sure what’s at fault there.
My biggest gripe is that I can't use the microphone at the same time as the headphones, without switching to tin can mode.