Yes, now that you mention it, that was also something I was afraid of when I made the fix originally, but I decided to go on an try it anyway to see if it had any problems. And after using it for a few months, without any issues I forgot about that.

And this is with a QMK based keyboard, where I do a lot of tricks. For example I have a key where I press `, which is a dead key, but it actual does ` + space as fast as the usb protocol can handle it, so the space is sent 1ms after the `. I also have keys that send shfit + key and then automatically releases the shift key, also within 1 ms. And even keys that first release the shift key, to send and alt gr plus some key, and then press the shift again.

That said, there might be some very special case where things goes wrong, so your fix is probably better.

As far as I understand, having messages coming from the keyboard in quick succession cannot trigger re-entrance by itself, because those messages become "queued" messages (not dispatched by PeekMessage).

The problem arises when another thread sends a "nonqueued" message to the winit window. Because PeekMessage dispatches "nonqueued" messages.

Yes, my point was more that it requires some very special circumstances to trigger any practical problems with the reversed event order. And that I would probably be more likely to notice them in my setup, than in other setups where the keyboard input is much slower, and PeekMessage wouldn't have a next key to read anyway.

Anyway, that was just an observation, fixing it correctly is obviously always better.