> there would certainly be close tags in that range that do not have matching open tags in the same range.

I think the way to handle that is to pre-seed the parser stack with all the tags that are open at the first affected position (which we can just look up in the existing DOM, since by definition none of those can have changed before the first affected position--where by "first" I mean "earliest in the document").

It's true we could be smarter and try to transform each successive change to figure out what the affected range is at each point, but we also don't have access to the marks at any of the intermediate stages, so we'd have to basically simulate CodeMirror's mark update algorithm too. Doesn't seem worth it unless we find major performance issues, and in any case if you're seeing multiple changes in a single changelist the user was probably doing some large operation like "replace all" anyway, so you might as well redo the whole thing.