Unfortunately the API contracts around here are fuzzy and untested, hence we are between a rock and a hard place. For direct users of DataTreeCandidateNode the current behavior makes sense. They know the node has appeared and if they choose to drill down, they will find the cause of the node's appearance, and this will be consistent with getChildNodes().

We could simply flip the reporting to the WRITE/DELETE codepath, but that would end up being inconsistent with getChildNodes() as well as create further problems with the type of descendant nodes – for example if we have two nested non-presence containers, they both should be reported as APPEARED when a leaf in the inner container is introduced. Changing the logic would pretend the inner container was actually written, which is the wrong outcome.

Hence it is up to Binding to deal with this difference and project a correct interpretation of the results. It certainly has all the tools required for the job.

This has been observed when LazyDataObjectModification.getModifiedChild() is asked to cross an BindingStructuralType.INVISIBLE_CONTAINER node disappearing. Current code assumes 1:1 correspondence with DOM model, which is wrong.

Since we are not reporting INVISIBLE_CONTAINERs, only their content, and we have a simplified ModificationType, which can only express WRITE/DELETE/SUBTREE_MODIFIED, we must treat a disappeared INVISIBLE_CONTAINER as a DELETE operation of all its children – i.e. not rely on DOM to provide correct answers here.

This is a side-effect of YANGTOOLS-938 and should be fixed there. With it applied, empty writes and deletes end up being DELETE modification types, hence making this a non-issue.