If we discount obsolete components, we have two remaining users of isAddedByUses():

1. CaseNodeCodecContext.createBindingArg(), which uses it to decide whether to use a case qualifier or not
2. Generators are using them for various tricks around ignoring statements and/or performing additional lookups

The first case should be moved to BindingRuntimeContext, and perhaps receive information about which CaseSchemaNodes should use the alternate Item.

The second case is the crux of the issue, as we need to discern the various uses and how they relate to MDSAL-696. Once we understand what logic (transitively) depends on accurate information, we can build the requisite bits of state into individual Generators.

The theory of operation is such that we have two guidelines from the parser: EffectiveStatement and its DeclaredStatement (if it was declared). There are a few rules:

1. if a statement's effective parent.getDeclared().substatements() contains that statement's getDeclared() object, then the statement has isAddedByUses() == false and isAugmenting() == false, otherwise
2. if a statement's getDeclared() can be (recursively) found in any grouping used by its parent, then the statement has isAddedByUses() == true
3. if a statements's getDeclared() can be (recursively) found in any augment attached to its parent, then the statement has isAugmenting() == true
4. if a statement has isAugmenting() == true and apply it's getDeclared() is found via method 2. by using its augment as a parent, then it also has isAddedByUses()

These rules need to be validated and they obviously contain a lot of poking around, hence we will to perform some score keeping while we resolve what's what. Also note this relies on inter-statement linkage be known, which in turn requires generators to be present – which is a chicken-and-egg problem.

Solving that amounts to performing incremental linkage, where we start populating the tree and remembering what statements are unresolved, and then proceed with attempting to link groupings and augments, reporting when either forward progress has been made or full subtree linkage has completed. If we fail to make any progress, we have found a bug and need to report that. Once we completely link modules, we can proceed with gathering the information for BindingRuntimeTypes.