>Here are the requirements (defined by how Python does things):
>1) Building an image from scratch (equivalent to Python creating an
>image in memory from *.py files loaded at run time by the core EXE)
>2) Loading modules (defining one or more classes) as needed from files
>(equivalent to the Python import statement)
>3) Supporting namespaces for a module for sanity and to ensure needed
>classes are loaded (like Python)
>4) Tagging modules with version numbers and checking they match
>acceptable versions when they are loaded (Python doesn't have this
>except as done adhoc by the code itself, so this would be an optional
>later part -- perhaps similar to ENVY)

Reasonable people may agree or disagree whether these are beneficial 
or even interesting tasks.  Squeak is not Python and Python is not 
Squeak.  If I wanted to code in Python, I'd still be hacking Python 
(my last stop on the way to Squeakdom).

I'm not sure what you mean by (1).  If you are suggesting the 
capacity to compile an image from a body source code, I see little 
advantage to (1), none at all in fact.  If you are suggesting the 
notion of building a single-file EXE, so what?  That's been doable in 
virtually all systems on which Squeak is supported -- though few have 
found much use for it either.

An interesting approach to (2) and (3) seems to be evolving from SqC, 
and I haven't felt so compelling a need beyond the very nicely 
developing hub and spoke project system that is evolving as recently 
as the last changeset.  I'm frankly more inclined to wait and see 
before moving along a parallel, and not obviously profitable, 
venture.  There has been a namespace system in place since 2.8a, of 
course -- yet nobody seems to have done very much with it despite the 
claims that it would lead to the next nirvahna.

Amusingly, despite all the accusations of SqC obliviousness to these 
"commercial-critical features," they seem to have carried most or all 
of the water on that project.

You are of course invited to do so, if you are so inclined to do so. 
Such is the virtue of an open source license.

I think that an ad hoc module-and-download "Goodie delivery system" 
can be built even in the absence of 2 and 3, and which would of 
course be enhanced by and benefit from (2) and (3) once fully 
manifest.  An enormously powerful system of delivery mechanics has 
been evident in Unix releases for years, despite massive conflicts of 
various kinds.  I like the structure of the FreeBSD "ports system" 
best, but other models can work as well.  I would be inclined to 
support this approach once I move along from my present projects. 
This could adequately fulfill most of the facilities of (4), and 
wouldn't require anything close to a fork for many versions to come.