Yes, maybe my 2-3 years is optimistic. I think ultimately it’s JS APIs for the native controls that need to be exposed rather than better contenteditable.
For example, what would an API look like to support international character combining? Or drag-select on mobile? Or custom keyboard inputs? How do you respect the user's OS level configuration - Like system-wide emacs shortcuts in macos, weird keyboards on samsung phones or overridden fonts for people with reduced vision?
Adding javascript APIs for all this stuff would hurt privacy on the web, because this data is full of entropy for anyone doing fingerprinting.
And it wouldn't even solve the problem. You'd still need user code (JS/WASM) to correctly implement platform-specific behaviour for everything to feel native. Thats a janky ride every time.
I'd much rather web browsers to just expose each platform's native rich text editing controls. They work great already. They already do accessibility, and have full support for the platform's native text editing controls and behaviour. And there's a precedent for this sort of thing - web browsers have had INPUT elements forever.
Inline blocks should probably be embedded DOM nodes or something - just like contentEditable does today. Then they can be themed & styled like everything else - using CSS.
There's some complex UX patterns to manage - like deciding what should happen if the user hits backspace when their cursor is right after an inline block element. If the user uses the keyboard to move the cursor "past" an inline block element, should the cursor enter the element or skip it?
This sounds like exactly the sort of problem that the web standards committee is designed for.