Regarding Scala, the main problem is the granularity: setting the visibility of each method individually goes far beyond the curly brace encapsulation model. I think the only reasonable way short of having a Scala VM is to keep generating accessors (or, as you suggested, making members public and reasoning about the accessibility at language level).
It seems that Scala's accessibility model is finer-grained than what the JVM has in mind. The JVM envisions three concentric rings -- everyone (public), library (package), and source file (private), plus the weirdness that is protected. Nestmates doesn't change that basic model, it just allows the compiler to have more latitude in clarifying the boundaries that determine private-ness (and to some degree protected-ness.)
Regarding Peter's question, I assume the reason you want to have a top of the nesting hierarchy is because you need to dynamically add new nestmates, which is easier to do in one place than in all nestmates. Right?
Dynamism is a part of it, but also (a) minimizing the error modes introduced by separate compilation and/or broken compilers (that then have to be checked at load time), and (b) minimizing the runtime overhead on classloading. The current proposal is very light in terms of the load-time overhead -- for a top class, you just have to record the NestTop attribute, and for a child class, you just have to validate it (which is a straight lookup.)
