I think not descending into a just-inserted-node makes total sense. By definition, you had to either unlink such a subtree from somewhere else or you had to forge it/create it. So, treating it like an atom in this iterator makes sense just as not descending the deleted node does. This solves the delete-then-insert right at the same spot problem, too. I think if you treat the inserts as "atoms" like the "deletes" it works out.
You might want to provide an API call named "replace" that does the delete/insert pair so client code can be clear about that. Not having the "iteration contract" mean descending into either seems the clean semantic. Just my opinion, of course. It might be worth searching for XML Tree (or HTML DOM) surgery APIs in other programming languages for ideas. Another possible use case of all this might be editing Nim ASTs in macros which I don't think has been mentioned thus far. (I didn't check IRC.)
