DISCLAIMER:  I am not (nor do I claim to be) an expert in these issues, but
I thought a stupid person's perspective would be valuable in this
discussion, since even folks like me want to take advantage of modules. :)

My experience with modules has really been with namespaces, which I've
used quite a bit in Java, and to a lesser extent in Lisp and Scheme.

An important thing when programming for me is (at least thinking) I have
an understanding of the semantics of scope and namespaces work.  To say
this another way, if what you think is going on is the same as what the
system will actually do. ;)

Scope is one issue, usually a straightforward one.  In Smalltalk, if you
reference a variable x, it may be (1) a local var of the current block (2)
a local var of the blocks in which the current block is enclosed, (3) a
local variable to the method, (4) an instance variable (which includes the
instance variables of the current class and superclasses), (5) a class
variable (again including the current class and its superclasses), or (6)
a pool dictionary, a concept I never mastered and haven't done so bad in
avoiding.  I think the lookup works like this and in roughly this order.

Inheritance is the other issue in Smalltalk.  Method calls start at the
receiver's class and go up the superclass chain, either getting handled or
throwing a doesNotUnderstand:. Calls to the pseudovariable super are a bit
different (method lookup starting at the superclass of the class of the
method's implementation, which is not necessarily the superclass of self),
and the metaclass hierarchy is weird.

Why do I digress to explain what everyone here probably knows better than
myself?  Because the importance is that we think about these things and
because they are deterministic.  We should know what happens.

What I like about packages / namespaces in Java is that, at compile time,
any issues about scope and namespaces are validated.  One can argue the
faults and merits of Java's namespace system, but the advantage I see is
that (a) decisions are compile-time, which avoids run-time overhead for
namespace resolution, (b) the compiler can help you catch name-space
errors, and (c) things are unlikely to change from underneath you.  This
is similar to package systems in Scheme.  The advantage of this scheme is
that I like the "early" binding of names makes it feel a bit more
deterministic than a very lazy binding system.

Features (a) and (c) are less true in Smalltalk.  I get plenty of
doesNotUnderstand:'s in the early stages of programming either because I
didn't initialize something (Smalltalk's SIGSEGV or NullPointerException,
I suppose) or because I passed the wrong message to the wrong object (do
circles draw on forms/canvases or can canvases draw circles?  Hmmm.)  It'd
be nice to have more of these caught, but they're not very common and they
are easy to fix.

A bigger issue is that in Smalltalk we're permitted and have grown
accustomed to adding messages to "fundamental" objects.  I have a
preferred way of printing Date objects that goes right along side the one
that is in the system, and I'm thrilled!  An issue in Modules / Namespaces
is to make this explicit:  I can add extensions to Date, and if I import
Module X I want to see X's extensions to Date.  Furthermore a "Core"
module for something like date that is automatically imported also seems
natural.

One issue that exists in Squeak is that there are already some schemes for
handling stuff.  I **LOVE** changesets and being able to look at previous
versions of code.  As a UNIX user who uses CVS extensively, the
ChangeSorter and Version browser is my friend. :)  We also have the
"Project" metaphor, especially important in Morphic, that already does
some kinds of encapsulation.  Finally, there is the update stream
mechanism which we currently use as a global mechanism.  This of course
brings up many questions for the ignorant, like

* How will modules change how changesets work?
* Will we have multiple update streams for the different modules? (This
seems natural and might allow multiple owners to maintain their own
module specific update streams, which may be good or bad)
* Can we somehow combine modules, update streams, and projects?  (This
seems especially beneficial because change sets and projects are already
connected.)  This would also be part of a somewhat grandiose vision I have
about how to deal with documentation in Squeak.  I think that projects are
a fantastic way to document how a module works.  They can be interactive,
are easily sharable and changeable, and many different projects can explore
different parts of the system.  I can write more if folks are interested.

====

I decided to stop rambling now and try to ask the question, "How will
modules impact how us unenlightened users use the system."  Specifically

1) How will language semantics (scope and inheritance) be affected?
2) Will modules be bound at compile time (file-in time) or execution-time?
3) What is the impact of modules on tools (browsers) and other existing
module-like schemes, like change sets, Projects, and update streams?

Finally, I'd like to thank the folks that are taking up the difficult
challenge of addressing this.  Like others, I think that modules are
definitely a Good Thing and can benefit the Open Source process, managing
complexity, learning the system, supporting collaborative development, and
many more.  I look forward to hearing more about this!

-Eric