Heap dump analysis of the L2FIB performance benchmark shows a large number of MaterializedContainerNodes and only a few LazyContainerNodes, which is exactly the opposite of what we'd expect to see with the expected usage pattern.

Investigation to the cause of this has revealed that AbstractNodeContainerModificationStrategy.applyTouch() will result in ContainerNode materialization even when the operation has no data representation effect because we bump the subtree version unconditionally.

This is not correct if the user has not specified any child operations (e.g. an empty merge) or if all of the child operations turn into no-ops. We already check for both these conditions to calculate the modification's effective type, but fail to take it into account with respect to ContainerNode lifecycle.

If a TOUCH operation result is UNMODIFIED, we can (and should) safely reuse the original ContainerNode without any modifications. This will prevent any false materialization and needless replacement of already-materialized ContainerNodes.