While that seems like a huge cluster, it does kind of seem that the patch rejections come from a set of principles. If the patches would improve Bluetooth audio at the expense of breaking existing features, saying "we don't break existing features" is a valid position to hold.

I don't think the issue was breaking existing features, it was a classic 'perfect being the enemy of good' situation. PA maintainers wanted to support dynamically loading the involved codecs due to potential (but not particularly well demonstrated) concerns about licensing and inclusion in certain distros. But they didn't really have the manpower to actually do this (and especially they disagreed with the person actually doing the work on how to go about doing this), so they just sat on an MR for ages while the situation improved for no-one (worst case it gets merged and then disabled at compile time by some distros). Meanwhile frustrations arose because the contributer wanted to help users and the maintainers just seemed like a roadblock to doing this, and the maintainers utterly failed to de-escalate the situation.

Isn't this probably because most developers have shifted focus on PipeWire? I thought both came from more-or-less the same community?

This is so sad. I had no idea.

Well whenever I report issues about pulse audio, the response I get is "this is fixed on pipewire". Seems like the development community has moved on and its time for the users to move too.