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?

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.)

Finally...I'm wondering if there's an edge case that looks like this. Start with:

`<p><img>orig text</p>`

Place the cursor before `orig text`, and paste in `new text<br>`. I'm not sure what the diff will do in this case, but let's suppose that it treats this as an insertion of a text node followed by the insertion of the `<br>` element node. (It might be that in this case it will actually do a text replace followed by two insertions, but I think we could construct a more complex scenario where you would get this kind of insertion.)

Now, when we generate the edits for this, the edit for the insertion of `new text` is fine, but now we have a problem when determining the position of `<br>`. Both neighbors are text nodes, so we actually can't say where to insert it, because it's not going immediately before or after an element, or at the beginning or end of a parent tag. I think that may be what the `textInserts` clause is trying to handle, but I don't see how it would help to keep the `afterID` in that case, because the browser-side code will still insert the `<br>` in the wrong location (before the `new text` node instead of after).