I think the solution to this conundrum lies with MDSAL-310's approach to fixing the problem. Essentially we can have two modes of addressing:
- direct child when unambiguous, crossing tables->linkstate-routes, as is the case when the container is outside of the grouping
- Intermediate addressing, which includes the item for the choice/case – requiring the user to specify the Case node (which would implement ChildOf<Tables>)
This is slightly confusing, though, as suddenly it looks like you should be able to read the case node directly from the data store... Which you probably don't want 
Unfortunately we do not generate proper grouping instantiations, hence we are not getting a class for 'container linkstate-routes' as instantiated by uses in case – that class would have ChildOf<Tables>.
Thinking about it a bit more, we really need a new marker interfaces:
- ChoiceIn<T>, which will mimic ChildOf<T> except being a DataObject
Then we need a new InstanceIdentifierBuilder method, which will have a prototype like:
<C extends ChoiceIn<? super T>, N extends ChildOf<? super C> InstanceIdentifierBuilder<N> caseChild(Class<C> caze, Class<N> child);
Hence access to a case's children (which is the problem here) is solved. This does not solve the problem addressing choices or their cases themselves.
To fix that problem, one of the two needs to budge:
- interfaces generated for choices would have to become a DataObject
- InstanceIdentifier<T extends DataObject> needs to be lowered to InstanceIdentifier<T extends DataContainer>
The first is not really an option, as DataObject guarantees implementation, whereas there can be no implementation for a choice. That leaves us with 2) as the only option.
That should work, as DataContainers are not subject of ChildOf, hence if you jump to a choice in InstanceIdentifierBuilder, you are stuck and cannot move down. This is fine for read/write, as you can move towards a particular case instantiation (which is a dataobject) via checking 'instanceof'.
The problem here, though, is DataTreeChangeListeners and MDSAL-342: it will suddenly become possible to subscribe to choices and we need to figure out whether that is something we want to allow – we can support it via overwrites, but the conversation around how you navigate downwards from there is ... dicey.
Hence let's focus this issue on solving addressing case/grouping children. MDSAL-342 then will deal with provide a similar API to arrive to modifications of ambiguous children. MDSAL-310 will then focus on addressability of choices and cases.