On Windows, if a WM_KEYDOWN produces a character, when this message is redispatched, its message result does not meet expectation.

Here's what should happen if a KeyA is pressed and the framework decides not to handle:

• System dispatches WM_KEYDOWN for KeyA, the message should be handled by the engine. (*1)
• System dispatches WM_CHAR for KeyA, the message should be handled by the engine.
• The framework decides not to handle this key event, so the engine redispatches it.
• System dispatches WM_KEYDOWN for KeyA, the message should not be handled by the engine. (*2)
• System dispatches WM_CHAR for KeyA, the message should not be handled by the engine.

Currently, there's no way to reach this behavior under our current structure, where message(*1) and message(*2) return different results, because such messages are returned before being sent to KeyboardKeyHandler (see code here), where redispatches are recorded. We need to refactor the keyboard system so that redispatching wraps message triaging.