The following self-contained [ime_test.c](https://gitlab.winehq.org/-/project/5/uploads/d54834a54cea2796f930d8be92eb37...) should show the desired behavior (Windows completely ignoring the IME processing for keys that are backtracked on) well.
If the application restores msg.wParam == VK_PROCESS back to msg.wParam = ImmGetVirtualKey(hwnd), then in NtUserTranslateMessage it no longer goes through the IMM/IME-related code path. Instead, it follows the NtUserToUnicodeEx route—that is, the normal keyboard driver WM_KEYDOWN processing path. So I’m wondering why the patch is being made in the IME code. But I may be misunderstanding the exact scenario in which this becomes a problem. By any chance, are you testing this with the "Japanese – Kana" or "2-Set Korean" keyboard input source? In the test program you provided, "Japanese - Kana": ``` IME detected VK_PROCESSKEY, Replacing with original VK: 0x0041 (A) WM_KEYDOWN: wParam = 0x0041 (A) scan=0x1E WM_CHAR / WM_IME_CHAR: char = 0x3061 (?) WM_KEYUP: wParam = 0x0041 (A) ``` Is this what you would like it to look like? ``` IME detected VK_PROCESSKEY, Replacing with original VK: 0x0041 (A) WM_KEYDOWN: wParam = 0x0041 (A) scan=0x1E WM_CHAR / WM_IME_CHAR: char = 0x0061 (a) WM_KEYUP: wParam = 0x0041 (A) ``` Then, this appears to be an issue within macdrv_ToUnicodeEx. With “Japanese – Kana,” the keycode-to-Hiragana mapping is also handled at the keyboard driver level. It might be easier to understand this by comparing it with "Japanese – Romanji". As far as I know, the IME input sources provided by macOS do not have an IME on/off mode, and we need to switch the input source in order to type A–Z characters. In other words, under normal IME input source conditions, macdrv_ToUnicodeEx is not usually called. In my opinion, it might be possible to handle this in macdrv_ToUnicodeEx by checking the result of macdrv_using_input_method(), although that could make the code a bit more complicated. Anyway, this is my analysis so far, and I hope this is useful, but I’m not certain. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9992#note_129514