In Section 3.1.8, upd:replaceNode, we see the following rules:

Rule 3 says that the target node (i.e., the node that was replaced) is "marked for deletion". 

Rule 4 says that the parent of the target node is updated so that the target node is no longer among its children or attributes.

But in the semantics of upd:applyUpdates, after all the primitive operations have been applied, we get around to processing the nodes that are "marked for deletion", and for each of these nodes, we update its parent so that the "marked" node is no longer among its children or attributes.

The problem here is that, in the case of a node that is replaced, the node gets removed from its parent twice: once by Rule 4 of upd:replaceNode, and once by Rule 2e of upd:applyUpdates.

I think the way to fix this redundancy is to change Rule 3 of Section 3.1.8 (upd:replaceNode) as follows:

3. Effect on $target: The parent property of $target is set to empty.

In this way, the job of detaching $target from its parent is done entirely by upd:replaceNode, and we no longer mark the replaced node for later deletion. The redundant operation on the parent of the deleted node disappears.

It is interesting to note that, when update primitives are applied in Section 3.2.2 (upd:applyUpdates), replaceNode primitives (Rule 2c) are applied before replaceElementContent primitives (Rule 2d). It is possible that both of these primitives might apply to the same node. In this case, Rule 2c will detach the node from its parent (but the node and its nodeid will still exist, without any parent), and then Rule 2d will replace the content of the node (this is a harmless thing to do but the modified node can no longer be reached from its parent.)

I request that the working group consider this proposal to modify Rule 3 of Section 3.1.8 as described above.

Regards, 
--Don Chamberlin