Hi Michael,

I think your approach sounds great and I will definitely try it out.

I can help integrate this with Monticello.

I can see this potentially help in moving the kernel forward, since new 
kernel module implementations
can co-exist with the old ones in the transition. I like the idea that 
when no one uses the old package it can simply disappear. (bye bye 
FileDirectory!)

For simple kernel class extensions and overrides, it is probably 
simplest to copy the whole class into the package. Lets call this the 
"copy and modify" approach.

However this could get difficult, since a package like Magma adds 
serialization methods to cover a lot of classes in the system, and these 
serialization methods do need access to all instVars. To support this 
there would have to be some notion of "Package A which is trusted to 
make extensions to Package B".... but what if I load Magma with the 
intention of extending all users of String, but actually users of 
My.String will miss out on those extensions. Also if you look at magma, 
you will find some classes which have method contributions from 
*magma-server, and contributions from *magma-client. There is a 
dovetailing of packages to make a whole. Perhaps this could be solved by 
having a specialized form of a class with is not a complete copy, but a 
wrapper around the original, with the extension methods. I call this the 
"link-to and extend" idea. Perhaps the additional methods could be 
defined in the form of a deltastream.

So it looks like we need a new paradigm for class extensions. If we 
could use deltastreams then we can have the idea of class extensions as 
a patch queue.

I also thought that if there is a  nominated "master" repository for 
each namespace, then the master repository could be updated with EVERY 
users adaptation.

So if I were the owner of Kernel.Foo and other people include Kernel.Foo 
in their namespaces, whenever they "copy and modify" Kernel.Foo within 
their namespace, my Kernel.Foo repository gets a copy of the changed 
version! That way I can make an effort to integrate any additions.  If 
users "link to and extend" my Kernel.Foo, then my repository would get a 
copy of the delta-stream that defines the extension.

I think that some social tools like this could help avoid the 
fragmentation that Göran hopes to avoid by only having one  
non-hierarchical namespace

Keith