NOLEGACY logic in queue_hardware_message: Not straightforward due to interactions with the hotkey and message altering logic earlier in the function (but, complexity aside, indeed seems to be a good way forward for a proper fix).
Well, don't assume that the way NOLEGACY is implemented right now is correct. It's apparently not and it was rather just part of a wider rawinput patch series and got upstreamed with it without much testing.
I'm not sure it's used by many applications, or rather not in a way that its interactions with other mechanisms is important: applications which use NOLEGACY then just don't care about most window messages, they are *only* interested in rawinput messages and use that flag to optimize the message processing.
A manual test shows that hotkeys messages are supposed to be received even with that flag, so basically moving the NOLEGACY check right after `find_hardware_message_window` looks like a simple fix and goes in the right direction.