Also they probably ended up where they were because if I remember correctly windows will 'smash' mouse move events together for you in some cases. This will look like 'lost messages' (I recognized the peek loop as I have done that same thing once). This is is for two reasons one old not needed as much any more, and the one they found out the hard way. Memory as just scrubbing the mouse around would create a ton of memory objects that need to be pretty much cleaned up right away. The second is performance. As that is a ton of little messages that need to be picked up looked at and something done with. Which zorches your CPU.
The core of the issue is trying to wrap polling style of logic into an event based system (which windows is at its heart). There is no real pretty way to fix it.
I think it would be probably best to handle it like real time audio, 8kHz is not far off anyway. Just collect mouse sensor data at a fixed sampling rate into a ring buffer, and don't try to have a separate complex object for each sample.
That would take care of the memory issue. It would need a way to tell the kernel to not send wm_* messages about it and a way to give the kernel a buffer to hold that data. However, you still have the overhead of processing the 'events' though or keeping up with the buffer.
yeah. I would be the old win3.x/2.x code probably just hung out on the ps2/serial bus interrupt waiting for junk to show up. Then sending a messages along when it happened. That 'behavior' would have to stick around for MS to hit its backwards compatibility goals. Either sampling or event spamming with a debounce buffer.
The core of the issue is trying to wrap polling style of logic into an event based system (which windows is at its heart). There is no real pretty way to fix it.