Folks -

Since we are talking about name spaces (and packages (and how they are or are not related)), I thought I would mention a point of view which has helped me to understand such topics in the past.  I have found it useful simply because, in the midst of many other  theoretical considerations, this one is entirely pragmatic, and therefore somehow easier to evaluate.

Whatever the module, whether it is a namespace, or a package, or a project (which I usually consider to be a combination of the two), or even something like an ImageSegment, the first questions asked are:

	If you load a new module, how does it affect the rest of the system?
	If you remove a module, how does it affect the rest of the system?

When you put these together, it suggests a desideratum:

	If you load a module and then unload it, you should not be able to tell it was ever loaded.

This is often casts a fresh light on the nature of the interface between each module and the rest of the system.  In the case of packages, it strongly suggests that (unchanged) source code be browsed from the package, rather than polluting the changes file.  In the case of projects, it calls out various issues in the handling of Symbols and global variables.  And at the highest level of the user model, it is meaningful as well.

I don't have a slant on the current name space discussions.  Well, I do, but I'm too busy, and I trust Andreas.  I just wanted to pass this along as a possibly useful metric during the engineering process of getting everything to work well.

	- Dan