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.
“Never break userland” is more of a strong guideline than a hard rule, even if Linus has sometimes made it sound otherwise during a heated gamer moment. The fact is, kernel devs break userland code all the time, sometimes because the alternative is worse, or sometimes because a bugfix broke something and no one noticed until much later and it was decided not to revert the fix because it would now break other things to do that. Try to run an entire large userland from 2001 on a modern kernel and tell me how that goes.
Mistakes are human. Certainly a lot of bugs slip through, and that's understandable, software is hard.
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
I mean, for whatever stupid and obscure reason, the manufacturer decided to hard-code the eraser button like that. The device was designed to have two erasers. If you used that tablet on Windows and switched to Linux, you'd notice the device wasn't working like it was supposed to. I can see why one would consider that a bug.
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.
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.