From what I understand, how it works in Win32 is that it is throttled based on how fast the app is reading the event loop. That is, if you get 3 or 4 mouse even

From what I understand, how it works in Win32 is that it is throttled based on how fast the app is reading the event loop. That is, if you get 3 or 4 mouse events while processing another mouse event, they will be "coalesced" as much as possible. And at least for the newer WM_POINTER APIs, it's possible for an app that cares enough, e.g. a digital painting app, to query for the events that have been coalesced, too. This seems OK to me and seems to cover the bases well enough. I don't think any compositor does this, but at least in theory it seems like you could do this using Wayland too, by just silently coalescing events when the client is behind on reading them. There's already a frame ID for input events, so in theory adding a protocol to go back and grab coalesced events using the frame ID seems like something you could do. I wouldn't be surprised if there's already some kind of solution like this somewhere, but at least it doesn't seem too hard to do if not. The one thing I will say is that Windows also had the concept of events having priority in addition.