DataSchemaContextNode is an abstract class, which has all sorts of composition going on and interdependencies, which means callers must know exactly what to do – and what to do is rather thoroughly undocumented.

DataSchemaContextNode should be an interface with other composable parts covering what operations are available and which not. The key decision here is whether the node is a mixin or not – which guards getDataSchemaNode() nullability because the only case when that is null is AugmentationContextNode, which is a mixin. Other decisions are data-driven, as leaf-list entries and keyed list entries require additional data for PathArgument – and at this point provide fakes.

It also seems the ordered/unordered subclasses could be better utilized, as they do not really provide user-visible value.

While we are at it and we have JPMS available, it would probably make sense to move the implementations into a private package, so as to reduce clutter in the public package (although things are package-private). The classes should have simpler names anyway – dropping the 'Node' prefix at the very least. A good name would be perhaps yang.data.util.impl.context, which indicates what they are just a context in which we execute a particular transformation.