I like viewing the future of Squeak as a world wide web of objects
(including classes, methods, etc), where VMs query and manipulate these
objects simultaneously.  Besides concurrency and security, the main
problem, as related to modularity, is maintaining copies of objects and
versions of objects that can be substituted for one another.

To help solve this, certain object pointers can be made indirect.  For
example, instead of an object pointing directly to its class it can
point to a Variable that points to its class.  When that object is
copied to another image the Variable can choose to resolve to a local
class or copy the original class as well.  Variables can be made smart,
to resolve to the local equivalent only if certain conditions are met or
to migrate the instance(s) using it to match the local equivalent.  Of
course, special subclasses of Variable can be made to handle different
circumstances.

Also to help make this work, symbols that represent objects should be
treated as pointers to those objects.  In particular, a selector is
really a reference to a set of methods that may be executed.  In the
absence of types, a selector refers to all methods in an image with that
name.  So when a method is copied to another image, the selectors it
contains should be replaced by Variables.  Each SelectorVariable can
either resolve to a local selector and thus refer to local methods, or
resolve to remote methods that will be copied (loaded) when needed.

In general, I'm proposing to keep objects as first class entities and
avoid statically partitioning them into modules.  Let the load
boundaries (segments) be determined dynamically and just provide help by
adding Variables to the object graph.

-Anthony