More than once the suggestions weren't breaking accessibility at all, and at least once it was GNOME devs deciding unilaterally that they know better than users who will face accessibility issues due to their changes.
Can you please give an example? Keep in mind that if a change fixes some accessibility issues for some people but then causes other accessibility regressions elsewhere, that could also be bad and not wanted. Nobody wants to be the person to make that decision and deal with the angry users, but sadly, somebody has to do it unilaterally otherwise development on the project will not happen.
Really now, if your stance is "it is bad for an open source maintainer to make decisions that might be difficult" then it seems you would have trouble finding any project that suits you.
Forcing single IME state globally and attempting to remove even the possibility of using per-window/application state in IBus. Mind you, this was removing the option, those who preferred single global state already could do so.
The argument was that it would lower cognitive load, without any evidence backing it up, and obviously with no input from people who regularly have to mix different input systems - where the ability for IME state to match context of the window they are in, especially as sometimes the different tasks in different windows would have incompatible needs on current IME state.
I honestly have no idea what you're talking about, I still see an option for "Allow different input sources for each window" in the keyboard settings panel.
I really don't understand why you are posting this, this is a 9 year old bug that is marked fixed. Please read the rest of the comments on the bug beyond that one and please don't make me regret asking these questions, I'm feeling like my time is wasted when people post these bugs without checking them.
Note that I'm not the person who originally brought this up.
I'm posting that because (a) I believe that is the issue referred to, (b) if you look at the reactions there is definitely a lot of "why would you even want this", there is the "lower cognitive load", and they did go ahead with a release in which it was broken, even though it was reported before the release was finalized.
Really now, if your stance is "it is bad for an open source maintainer to make decisions that might be difficult" then it seems you would have trouble finding any project that suits you.