DataNodeIdentifier is our candidate for yang.common's representation of YANG's instance-identifier type.

RFC7950 defines four places where a 'default' statement can occur, which boil down to two distinct kinds:

1. when used under a 'typedef', a 'leaf' or a 'leaf-list', where it binds to the value domain (i.e. boils down to one of the built-in types, perhaps restricted)
2. when used under a 'choice', where it binds to a child case identifier, i.e. it boils down to QName along the SchemaNodeIdentifier axis

The value domain part a bit thorny where 'instance-identifier', 'leafref' and 'identityref' type are concerned, as they differ in how namespaces are bound. In both cases qualified qnames are bound at the declaration site, but then unqualified qnames are

1. bound at the declaration site for 'typedef' default
2. bound at the particular instantiation site for 'leaf' and 'leaf-list' default

We need to consider all of these in this design. I think we can expend some memory in making an indirection, i.e. to have a DefaultArg interface and that providing access to values. I think it is fair for parser implementation to provide QualifedBound values for leaf/leaf-list, just as is the case with XPath expressions. Users usually have the means to understand the default namespace at the instantiation site.

The other part is that we need to understand how the type system is wired before we call DefaultStatementSupport.parseArgument(), simply because we want immutable classes and in order to correctly interpret the incoming string we need to know in what domain it resides.

This implies that all statements which could potentially be holding back a default statement must be present in a previous phase – and must gate its finalization of that previous phase with inference actions, so that when that previous phase completes, 'default's parent has either a populated namespace, or can reconstruct that information on demand (for example via a vritual namespace?).