One thing I've realized playing with a ton of different editors is that contenteditable gives you one very important feature that you can't fake yourself: access to the browser's spell check and corrections. It's possible that CKEditor ignores everything else about contenteditable, but turns it on just for red squigglies.
Using those, implementing IME should be relatively easy. The events tell you which partial characters to show, and which completed characters to insert.
Listening to these events and using DOM diffing can get you a more or less accurate idea of what happened. But 'relatively easy' does not apply.
I have yet to find a free contenteditable-based WYSIWYG editor that works properly with the Korean IME in recent versions of iOS. Duplicate characters everywhere. Even the Enter key sometimes works and sometimes doesn't, depending on what character is immediately before the line break. Froala is better, thanks to a Korean guy who helped develop a fix for them despite the fact that it's not even FOSS.
As much as it is doable for standalone editing, it is a nightmare for collaborative editing, where content changes all the time - not only at the place where you type. Each content change may cause composition (IME) to break. That's how the browser works.
This is one of the reasons why "real-time collaborative editing" solutions often implement "block limiting" -- one block/paragraph can be edited only by one user at the same time.
Enabling IME will be one of the toughest goals for CKE5's collaborative editing solution - Letters: https://ckeditor.com/letters/
I covered the "Can't it be avoided?" section in this article a couple of years ago: https://medium.com/content-uneditable/contenteditable-the-go...
tl;dr: Unless browsers will open for the Web multiple crucial features (such as IME, keyboard, selection, touch, on-screen keyboard, spellchecker, etc.) contentEditable is the only sane way to handle text editing.
There's an ongoing initiative to fix this situation but it's an extremely complicated topic. I wrote a few words about it in https://medium.com/content-uneditable/fixing-contenteditable... but later things got even more tricky. Since then I've been on W3C's meeting in Paris and contributed to many discussions about the standards and I can say that this whole topic makes even the most experienced browser people suffer when trying to solve it. Fortunately, 2 years later I can still say that things move forward. E.g. the beforeinput event landed in a couple of browsers.
There is a route you can go that doesn’t use contenteditable, except as a small box at the cursor position to handle IME; it’s what Google Docs does. At my most recent job (stealth start-up) we built an editor like this, painting our own selection and everything. It makes certain things easy or possible — custom text wrapping, tab stops, custom handling of cursor and selection with regard to embeds. It doesn’t get you very far on mobile web, though.