I think your idea with a Instance stack requires that the instances cash their placement relative to the next toplevel instance, or to toplevel in document. As a instance could have multiple parent instances they need to cash a list of parent placements, one for each parent? I think kind of cashing is problematic, as normally objects do not see any change that happens elsewhere in the document. Now if a instance is moved from one container to annother or gets added to annother container which has annother parent Instance the instance in question does not know that and the cashed placements are invalid. I think for for this to work one needs a new recompute system to globally inform objects of global changes? This sounds very problematic.
If one would like to avoid that kind of recompute system changes one would calculate the instance placements always on the fly, just traversing the grah upwards. With the jriegel changes this will be fast and efficient. But than a generall question arises: why an special object for instances?
How I understand it, 95% of what you like to do with instances also works with Instance==GeoFeatureGroup.
1. A GeoFeatureGroup which allows only a single object in its Group
2. The Viewprovidere would not show the childs in the tree
IMHO this is exactly what you want, except for the array functionality you described. Why not a new object would be beneficial:
1. Graph traversing would be general, you don't need to handle multiple objects, just GeoFeatureGroups. This makes the logic way simpler and more consitant.
2. No hard code changes as you described in the new Extension multiple inheritance approach. There is no need for a localCS that behaves different and is a different type than all other localCS.
For array functionality: For this you need to add a special handling interface to Instances anyway. It is easily possible to extend the GeoFeatureGroupExtension to allow offer this functionality. I don't think a new object is less work.
Honestly I don't see the benefits of a complete new Instance object compared to GeoFeatrureGroup. So I think it could come down to a merge of our two approaches: Stacking localCS like I proposed in GeoFeatureGroups, but with tree behaviour/User interface like you proposed. Assuming this approach, could you think of any functionality which would not be possible with this approach?