We also probably need a better way to integrate host IMEs as it would be unfortunate to unconditionally return TRUE from ImeProcessKey, and it would be better to only do so if there's an actual IME to be fed on the host side.
At least on the Cocoa side of things I don't think there is a good way to do this even using private APIs (as in asking the native IME if it would consume a key event).
I'm not completely clear on what it implies, like whether normal keyboard message need to be restored and where (or whether this is already working or not), and this could perhaps also be added to these tests.
Unfortunately in my windows VM for some reason the non interactive IME tests still do not generate a VK_PROCESSKEY when using SendInput/keybd_event instead of physically pressing the key... But maybe this can be solved more elegantly somehow rather than interpreting the success of ImeToAsciiEx in the user driver, although I think it still makes sense to handle this in win32u in a more unified way. I am also not familiar with the inner workings of how this is handled on winex11 there; this patch was designed to be a no-op though for all other drivers. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9992#note_129512