If I understand correctly, the "top" class is there just to simplify the calculation of whether two classes belong to the same nest.
It's a little more than that, but this is part of it. Having a canonical member simplifies the calculation of "are A and B members of the same nest." Conveniently, there *is* an obvious canonical member, so we might as well not make our life harder.
We need a way to refer to a nest. Having a canonical member is ideal for that.
We need some way of (in)validating the claim "I am a member of the same nest as java.lang.String". Having a canonical member, who can answer such questions authoritatively, is ideal for that.
Because the intention is that "nest" corresponds to some logically grouped source unit, and therefore a class may be a member of only one nest, we need some way of enforcing that a nest forms a partition. Having a canonical member makes this far easier.
Are there any other functions that might be attached to the "top" class? Will the top class have to be loaded in order to verify access of one peer to another peer? Or will it just have to be parsed to extract the NestTop attribute?
The obvious implementation strategies would likely bring us there. It is conceivable that we could delay loading the Top until its nest-ness credentials are needed, but that seems like it would add a lot of implementation complexity (and would keep us from failing fast.) So its likely that this would happen.
However, this seems pretty likely without nestmate-ness too. How often do we instantiate an enclosed class without loading the enclosing class? (Never for instance inner classes.) It happens, but usually only in cases where nesting is used "for organizational purposes only" (and in those cases, the enclosing class is usually trivial.) So this doesn't seem a terrible constraint to me.
What other functions did you have in mind for what the Top can do to help its children?
