Below is a module design that varies slightly from the current one but
allows storage of arbitrary objects and has a different dependency
structure.  Database transactions are also introduced; they are
orthogonal to modules but are used to load and save modules.

	Modules are organized in a multiple inheritance hierarchy.  Each module
provides a name space that contains the names of its local root objects
plus the root names of all inherited modules.  Names are searched in
topological sort order, ambiguous names raise an error (This search is
only required during compiling or module loading).
	Every object belongs to one and only one module.  When saved to disk,
an object pointer that crosses a module boundary is converted to a disk
pointer containing a relative path name, and the referenced object
becomes a root of its module if it is not already.  The relative path to
an inherited object is equal to its root name (disambiguated if
necessary) allowing overriding.  The relative path to an object not
inherited is equal to its top-down module path from the closest common
parent.
	Methods are compiled with respect to their owning module (remember
every object belongs to a single module).  Selectors and globals are
looked up in the modules name space.  Ambiguities are presented to the
user allowing him to choose a specific inheritance path to disambiguate.
 Selectors, like globals, are root objects of modules.  Instead of
storing selectors in a global symbol table, they are stored in modules. 
The same selector name in two different modules will be treated as
different selectors, compiling will bind the method header and message
sends to one or the other.
	When a disk pointer is traversed its referenced module is automatically
loaded.  All disk pointers in the image that reference that module will
be converted to regular pointers pointing to their object at the end of
their relative paths.
	New objects are added to the current working module (like current
Project today) and recorded in the current database transaction. 
Changes to existing objects are also recorded in the current database
transaction.  The current working module may change while maintaining
the same current transaction.  Upon commit all changes recorded in the
current transaction are saved to the active database.  The transaction
also records which modules were loaded and when, so the database will be
able to tell if the commit is safe (ie. no one else has changed the
modules read in the mean time).  We could also allow multiple pending
transactions and nested transactions.
	The database contains all Squeak modules.  The database can be
replicated for load balancing, and forked to allow different variants
(like 'stable' versus 'alpha' versus 'personal').  Transactions are not
forgotten when commited, they are kept around as database layers.  A
layer can be copied and applied to another database if it does not
introduce inconsistencies.  A layer can be broken apart or merged into
another layer.  A layer would be equivalent to today's changesets.

What do you all think?

Cheers,
Anthony