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.
The problem that this is supposed to fix primarily is not feeding the `A` character at all into the native IME system in that scenario, which the current implementation does (the test is more about observing this effect). The resulting `WM_CHAR` is still wrong there, but that is only secondary to the issue.
Fwiw regarding IME detection I think a solution (which also applies to other platforms where it might be hard as well) would be to have a mapping of well known non-IME host keyboard layouts, as a hardcoded name list if we can't do better, mapped to their corresponding well-known Windows HKL values, and every unknown host layout exposed as a generic Wine IME HKL, with the IME HKL bit set, as any other native IMEs.
This already works pretty well as it is with `macdrv_using_input_method(void)`, although it would indeed be nicer to have this on a per-key granularity, instead of per-layout, but I think that is the best that can currently be done. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9992#note_129743