Sure, remapping "belongs" to the input layer, but there are use-cases that aren't possible if you do this. I've had a few situations in the past where I had to

Sure, remapping "belongs" to the input layer, but there are use-cases that aren't possible if you do this. I've had a few situations in the past where I had to do window-level button remapping. I had programs that had hard-coded keyboard shortcuts for keys that my keyboard simply didn't have and remapping them for the whole system would've screwed up every other program. If you go further and expand input remapping to also inclue macros you'll also soon find the need to send input directly to a window. There are also many cases where a simple remap won't do since there isn't a single "originating" input event (like remapping joystick movement to WASD or faking inputs from non-input device events). This makes any such API fairly complex and you'd have to be implementing something like it in the compositor/window manager/DE anyways, so why bother also doing it at the input layer? Where Wayland went wrong is ignoring these use cases and putting the burden of making APIs for them on compositors, which of course couldn't agree on anything, so now we have nothing. Evdev works at a very low level, so many things aren't possible, libinput doesn't expose its APIs externally anyways and the only compositor with even rudimentary input mapping support is KWin and that barely works.