Basically, for message-based devices like mice, because the RawInput API just simply posts messages to the application's message queue, the events arrive in exactly the order as had been generated by the hardware. All the application needs to do is to process them message-by-message, rather than lumping the result together as a single state.
In the glfw code you linked, you can see that they use `PeekMessage` as a non-blocking way to check for presence of events in the message queue. This is also the case for basically every other frameworks too like SDL2, when what they should be doing instead is have a separate lightweight thread that runs the blocking `GetMessage` counterpart, and the very first line to execute right after `while GetMessage` is to query the high-precision timer to timestamp the exact instant that the OS places the message in the queue.
Frameworks that offer "blocking" versions of their API call don't actually use the blocking call, they just simply skips the game loop until they happened to poll a message, so it is still beholden to the poll timing rather than the OS's unblock timing.
2)
Thanks, I actually found the same link after Googling the tutorial name of the rotted link. I'm actually looking to have Rust as my "main" system programming language.
However, the biggest annoyances for all of the compiled language that I've surveyed is the lack of a "dummy-proof" portable way to set up the toolchain, unlike AutoIt where I can drag the text file to an exe and instantly test it. I really dislike having dependencies installed on my main OS; Docker as a "click and forget" compiler was promising at first but the setup process is still something that I had to look up, which just eventually became too much of a cognitive hassle and ended up reverting to the "easy prototyping" languages whenever I'm doing anything exploratory, which means that I never ended up having those exploratory scenarios being applied on the languages that I needed to familiarize myself with.