> because it doesn't know anything about windows or focus
But that's exactly the problem with the Wayland architecture, isn't it? Input handling, window management and composition are so closely entangled that it shouldn't be spread over several unrelated libraries.
And yet, in every other OS, scroll speed is a global setting, potentially with per-app overrides. No user in their right mind will configure a different scrolling speed in each and every app they use - they will have a preferred scrolling speed, and at most a handful of apps where they want custom behavior (e.g. scrolling in a game will probably require completely different precision than day-to-day, or perhaps a CAD tool).
It's the same argument that the libinput author makes about why libinput doesn't implement kinetic scrolling, and that it's the job of the toolkit. Only the toolkit knows what's appropriate there.
For reference, the kinetic scrolling rationale goes like this: say you start a scroll movement in one app, and then it continues scrolling after you lift your finger off the touchpad. Then you alt-tab to another app. If libinput implements kinetic scrolling, then scrolling will start happening in the newly-focused app, until the kinetic scroll decays down to zero. That's definitely not what you want, and libinput can't fix that problem, because it doesn't know anything about windows or focus.
Granted, scroll speed isn't exactly the same thing, but I could imagine that a toolkit/application could want different scrolling speed in different contexts, which libinput would have no understanding of.