If a 'fix' broke something (and it's not for something like a major security issue), then it is customary to revert the fix and go back to the drawing board
I can see that this is a complicated situation and OP was a special case that had not been affected by acccident, but those are excuses
If you upgrade your kernel and you don't have any out of tree stuff, by policy nothing should break, orherwise it's the kernel's problem.
That being said, I find that people tend to take the no regression rule pretty seriously, if you bring a valid complaint. It makes good sense. We don't want to give people a reason to stay on old kernels even more than they do today (this post written on an ancient Android kernel, chock full of out of tree drivers). We can at least save people from pain when it comes to in-tree drivers.
I think we really all benefit from that policy. Even if it sometimes keeps some less than perfect workarounds in the code
One user asks "why is my right click an eraser now", another asks "why is my eraser a right click on Linux". Which one is right?
To resolve this, the devs could've added an easy setting somewhere to control this behaviour, but I still think this can be considered a reasonable bugfix as the manufacturer decided on this stupid design. Linux drivers used to hack around that, but that's a classic XKCD 1172 problem.
I see what you did there