So digging into the problems here, we need to start with mdsal-binding-dom-codec-api, specifically with BindingCodecTreeNode hierarchy.

BindingCodecTreeNode is okay, as it only exposes underlying yang.model.api contract.
BindingObjectCodecTreeNode is okay as well, as it just adds the notion that there is a corresponding BindingObject class

BindingDataObjectCodecTreeNode is where the trouble starts. Aside from specilizing the corresponding class to a DataObject, it also implies there is a corresponding yang.data.api.schema contract, namely:

1. it has serializePathArgument() and deserializePathArgument() – but these already acknowledge there is no 1:1 mapping: LeafNode NodeIdentifiers do not have a InstanceIdentifier.PathArgument and Binding "case" interfaces do not have a YangInstanceIdentifier.PathArgument, for example
2. it is also a BindingNormalizedNodeCodec, which offers direct translation between a DataObject and a NormalizedNode
3. createCachingCodec() seems misplaced and should be moved to BindingNormalizedNodeCodec (as it is part of that aspect)
4. writeAsNormalizedNode(), which is under-specified and seems to be only used by the codec implementation internally and originates with the initial cut for these APIs in https://git.opendaylight.org/gerrit/c/yangtools/+/15964

So that gives us three items to look into

1. move createCachingCodec() and writeAsNormalizedNode() into BindingNormalizedNodeCodec, iff its hierarchy is ready to do that – otherwise we need to introduce a BindingNormalizedNodeCodec specialization
2. look into the 'implements BindingNormalizedNodeCodec' part – it feels like this should be another specialization, or perhaps an accessor method i.e. "BindingNormalizedNodeCodec normalizedCodec()", anyway see below
3. look into the PathArgument translation methods – but we do not need to deal with that right now

The second order of business is BindingNormalizedNodeCodec itself. As such it assumes a 1:1 mapping for all BindingObjects, i.e. there is a NormalizedNode which holds the equivalent data. In and of itself this is okay, as that is true for most constructs, but here we are looking for something different:

• in the NormalizedNode -> Augmentation direction, we are taking the parent, which is very much expected to be a DataContainerNode and we project some of its children into the Augmentation
• in the Augmentation -> NormalizedNode direction we are producing a collection of parent's children

The second point is important for mdsal-binding-dom-adaptor, as it needs to recognize this fact and deal with translating whatever mdsal-binding-api operation is being mirrored to mdsal-dom-api. We therefore have to have a type-safe way of discerning the two cases (which ties back to item 2. above).