I once used ContentEditable combined with Angular JS. It was the single worst UX development experience in my life. What a terrible control. I was trying to make an interface that binded an array of models, which had individual properties that bound to a properties panel on the side. Editing the property panel would instantly update the text, and updating the text would update the property panel. (the way i'm describing it you might wonder why do you need it in two places, but i assure you it made a bunch of sense... and was a super cool idea).
I ran into the problem though that if you accidentally deleted the text, but than tried to write it again all the bindings instantly broke. Or conversely you might start writing some text with the intent of it being outside the binded area, but it would still be inside... so the analysis that set the property panel control didn't work as expected.
I eventually got something that worked... but it was far from the original vision. I never really did figure out how to gracefully work with the control.
Frankly, it's not surprising that what you describe was difficult. Very few libraries would have been designed with that sort of "updates in both directions" architecture in mind.
It could me possible if contentEditable had events that corresponded to edits that were about to happen. Instead it just emits the raw interactions (e.g. keypress) and then mutates the DOM. It's very easy to get a mutation cannot be retroactively mapped to an edit.
I ran into the problem though that if you accidentally deleted the text, but than tried to write it again all the bindings instantly broke. Or conversely you might start writing some text with the intent of it being outside the binded area, but it would still be inside... so the analysis that set the property panel control didn't work as expected.
I eventually got something that worked... but it was far from the original vision. I never really did figure out how to gracefully work with the control.