The idea is to have:

public interface ContainerNode extends Map.Entry<NodeIdentifier, ContainerNodeState>
        [ extends SchemaNode state mess],
        Identifiable<NodeIdentifier>, ContainerNodeState {

    default NodeIdentifier getIdentifier() {
       return getKey();
    }
}

public class DefaultContainerNode extends AbstractMap.ImmutableSimpleEntry<NodeIdentifier, ContainerNodeState> implements ContainerNode {

}

which would be a compat view. Except naming sucks – is much better to not lug around "State" suffix in most places. It also has performance implications on streaming API, where we really want to propagate these from a Map.entrySet(), otherwise we could end up hurting the GC.

I do not believe we can deliver this in Aluminium.

The entry part of this proposal needs to be provided separately, as it would end up propagating type. The idea is that NormalizedNode is semantically equivalent to Entry<PathArgument, ? extends Object>, but we do not express that as a generic parameter by rather through an

NormalizedNode {
  default Entry<? extends PathArgument, ? extends Object> toEntry() {
    return Map.entry(getIdentifier(), body());
  }
}

We then override this method to provide more precise approcimation, so that:

ContainerNode extends NormalizedNode {
  @Override
  NodeIdentifier getIdentifier();

  @Override
  ContainerBody body()

  @Override
  default Entry<NodeIdentifier, ContainerBody> toEntry() {
    return Map.entry(getIdentifier(), body());
  }
}

We need the equivalent of ContainerBody for every NormalizedNode so that nodes can reconstructed easily. ForeignDataNodes are an exception: their body is a foreign representation, which we know nothing about (it can be a DOMSource).

There is an interesting conflict between LeafNode and AnydataNode: how do we know an AnydataNode is not represented as a byte[], which is the same as a leaf for 'type binary'.
It seems this issue is a bit more thorny: we certainly want to solve ContainerNode (due to identifier) and LeafNode/LeafSetEntryNode (for memory efficiency), but others perhaps can be left alone for later.

If we scope out those two, they boil down to:

• ValueNode, which covers LeafNode and LeafSetEntryNode. When dealing with reconstitution, LeafSetEntryNode can be known to be allowed only in LeafSetNodes and LeafNode is a DataContainerChild which implies its parent is a DataContainerNode
• ContainerNode is a DataContainerNode (and DataContainerChild which adds guidance from ValueNode)

Looking at DataContainerNode, it is a DistinctNodeContainer (implying child addressability) and has three specializations:

• ContainerNode
• LeafSetNode (note: addressability is wild – either linear position for ordered, or identifier for unordered, this is still subject to evolution)
• MapNode (addressability, but shares ordering w.r.t. UserMapNode/UserLeafSetNode)

DataContainerNode itself covers AugmentatioNode (which is going away) and ChoiceNode, ContainerNode, MapEntryNode, MountPointNode, UnkeyedListEntryNode – not all of which reap the memory benefits.