If the problem was with the keyboard, then this flaw would also be identified in beta version 7.63.416.

Thanks for the feedback.

So we've established that you are seeing this issue in custom @windows in v7.63 as well. The reason it affects non-custom windows in the latest beta is that the on KEYDOWN/UP/CHAR events were enabled for all windows.

It is very likely due to the way ToUnicode() handles dead keys. However, it is odd that I, and other users, have not been able to reproduce the issue. I am also using Windows 10 Pro, English, and have tested with different keyboard languages/layouts.

And as you are not seeing the issue in other applications, it is not likely to be a keyboard driver issue. That said, if you happen to have another keyboard lying around... does it behave the same way?

I will be making a change to the way ToUnicode() is called that prevents it from affecting keyboard states, an option that Microsoft added to ToUnicode() in Windows 10 1607.

Let's see how that works out in the next beta.