The biggest problem is that the policy association between what the hardware and firmware provide and what the expected behaviour is vary between releases of Wi

The biggest problem is that the policy association between what the hardware and firmware provide and what the expected behaviour is vary between releases of Windows, and so having the kernel make that kind of association leads to problems. The goal of doing stuff with a userland library was to leave the mechanism up to the kernel (ie, expose the various different ways of driving the hardware) and allow userland to make a policy decision over which interface was least likely to cause confusion. If you're having to write shell scripts then there's absolutely a failure - but I haven't bought a laptop in years where that's been the case (and I stopped doing this stuff professionally a few years ago, so I really do appreciate stuff working out of the box). Desktop environments should be providing the necessary glue to bind keys to something that can make an appropriate decision while still allowing overrides for the corner cases that the kernel can't catch. Systemd actually makes it easier to handle a lot of these -it provides a centralised mechanism for exposing platform-specific quirks to other userland components. I'm not going defend every systemd design decision, but honestly it's been an improvement for everything discussed in this post.