(Probably other platform may need specific support as well, this issue only intend to track win32)

Win32 exposes number of IME-related message to let application handle, most notably
WM_IME_SETCONTEXT / WM_IME_STARTCOMPOSITION / WM_IME_COMPOSITION / WM_IME_ENDCOMPOSITION / WM_INPUTLANGCHANGE (and few others like WM_IME_CHAR).

These message requires specific processing and return value of LRESULT based on processing - i.e for WM_IME_SETCONTEXT,

1. Application decides to create own IME wnd or not, calling ImmIsUIMessage. If it created one, clear ISC_SHOWUICOMPOSITIONWINDOW from lparam.
2. if application called ImmIsUIMessage or DefWindowProc for own IME managing, return it's return valus as LRESULT, or just forward message to DefWindowProc and return it's value as LRESULT.
3. Once application owns IME handling, other IME messages (i.e WM_IME_COMPOSITION) should not forward message to DefWindowProc, instead have to foward it to own IME window instead.

Couple of things I couldn't wrap my head around for those implementation are

• How to event loop get LRESULT value from callback, if application processed it / determine if it wasn't processed by application callback
• This requires application need to specifically manage ImmIsUIMessage (or DefWindowProc per preferences) when decided to manage IME handling, probably too low level exposure. Maybe there need to be some sort of manager to wraps up? (and those manager also stores context of application level IME status, manages forward message to DefWindowProc or not as well)