> Is there a symmetric case we need to deal with here, where the new element is being inserted before an existing text node, and so we should delete edit.beforeID since it's not valid?

It turns out that we don't need this at the moment because of a suboptimal diff generation. The text between the elements is deleted first and then the element is inserted and the text is re-inserted. That's ugly but not a showstopper. I'll file a bug on that, because I haven't already.

> Also, I'm a little confused about the !textInserts[text.tagID] clause here. Even if the neighboring text node is a new insert, doesn't that still invalidate the afterID? (Since we want to insert after the text node, not after the previous element.)

That code is actually not needed right now. It's a holdover from the implementation that had `afterText`.


One thing I have on my todo list is "insert a new element in the middle of some text". Feel free to add more tests, because that is the key thing we're doing right now.