This essentially means we have to maintain type information across serialization. I think we need a typical use case where this would apply, because this has non-trivial storage cost.

In order to express the requirement at yang-data-api level, each leaf's value has to also include the TypeDefinition of the type, adding one layer of encapsulation:

// T being 'String' in this case
public interface ValueNode<@Nonnull T> {

    TypeDefinition getType();

    T getValue();
}

leading to

public interface LeafNode<V> {

    ValueNode<V> getValue();
}

Note that XML/JSON would require annotations to preserve this information for all data, as we cannot assume that receiver is not observing ambiguities (such as a derived type we are not aware of).

For leaf and leaf-lists this will incur additional 24-32 bytes per-instance cost until Java grows support for value types (dropping it to 8-12 bytes).

If we decide to pay this cost (and perform the migration), we can also extend this to NormalizedNode, where that cost is only 4-8 bytes.

MDSAL-440 has delivered the most critical bit of functionality of this issue, as both of those returned objects will compare as equal.

As the generated code getter will return Uri, user code wanting to forward the object towards a user which expects SpecializedUri can use an instanceof check and an explicit conversion.

This issue can make that easier by exposing a utility static converter, which will integrate check/cast and conversion to SerializedUri – we already have an efficient constructor anyway.