It's beyond my knowledge to guess the exact reason this MR is being delayed. Maybe I should have just waited.
I think there is a slight issue in v8.
I tried blocking messages using WndProc hooking in the default ime window and ime ui window. In my opinion, messages like WM_IME_COMPOSITION do not appear to be triggered by WM_IME_NOTIFY. Even when I blocked messages like WM_IME_NOTIFY, I was still getting WM_IME_COMPOSITION messages. Also, since the message is "SEND", the sequence of messages should be recursive, but it isn't.
Of course, you're probably just borrowing the idea, not the exact implementation of the native behavior.
Also, if your app WinProc blocks WM_IME_NOTIFY messages without passing them to DefWindowProc, v8 will not work.
If an app draws all the ime UI elements by itself, the app WndProc will block the ime messages. This was true up to Win7. Honestly, I'm not sure about this in Win10. I'm not sure how to control the visibility of candidate window, maybe it requires TSF programming. Anyway, my opinion is that it's probably better not to rely on WM_IME_NOTIFY.
If you use 0x287(WM_IME_INTERNAL) message, you should be able to escape these issues without much modification in v8. Unlike the original implementation, v8 seems to have no problem using 0x287, but I'm not sure you'll like it.
Even if 0x287 is blocked for some reason, it doesn't matter because there's already no IME processing happening at that point. Same goes for native.
Also, the arrival of ime messages in the app window seemed to be independent of whether or not an ime ui window was created.
This is an issue I inferred from a test program, so I don't know if it will show up as a real app issue.