It was already refactored, into libinput. The issue with testability is not about the code being badly architected. The fact is if you have 100 config options and 1000 supported hardware devices, you must test all possible options and now your test matrix has something on the order of 2 ^ 100 * 1000 cases to go through. This combinatorial explosion is unsustainable.
I personally disagree that device quirks should be straightforward for the end-user. The end-user shouldn't even care about this, the point is to make it so they don't have to mess with config files or a hardware database at all.
I can come up with architectures which avoid the combinatorial explosion of test cases. Most of these hinge on two pieces of architecture and one of organization:
1) Giving drivers ways to expose additional functionality through extensions (a thin pass-through)
2) Giving abstract APIs which allow transformations between the input and the output
3) Having the mess live outside. The maintainer maintains interfaces, but not the exponential explosion of one-of-features and quirks.
Examples of such architectures include themable / programmable window managers (e.g. Enlightment/xmonad/etc.), Photoshop/gimp filters/extensions, or EMACS.
Whether or not this is a good idea is a different question. I don't have an opinion there. I definitely would have had time playing with something like this as a teenager. I just expect things to work as an adult with adult responsibilities. A lot of this comes down to target audience, resources available, and other questions which I have zero insight into.
They may want to care because not every device will be in the hw database at the outset. Or the existing description may be incomplete, and fail to account for something that libinput supports. Good hardware support starts from users "scratching their own itch" by experimenting with "advanced", less-strictly-supported options to reach the best combination for their hardware, and perhaps their niche use cases. Testability is a red herring because only a few advanced options will ever be applicable; the issue is that they're different options for different cases.
It's not a red herring. Those advanced options still need to be tested and maintained. If no one tests and maintains those options, they will break and users will complain again and you're right back where you started. The idea is that it's better to just remove them instead of creating a false expectation that they're going to work. I personally would agree with that decision, at least in this case anyway.
In libinput, people who understand the problem and are willing to work with the developers and contribute upstream can edit the hardware quirks. The maintainer has also blogged about this: https://who-t.blogspot.com/2018/06/libinput-and-its-device-q...
I personally disagree that device quirks should be straightforward for the end-user. The end-user shouldn't even care about this, the point is to make it so they don't have to mess with config files or a hardware database at all.