Thanks for your reply, Anthony!  Below are my responses to some of your
points.

I asked:
>> What could be done in (B) that couldn't be done at all in (A)?
>>  Or in what cases would (B) provide a more enjoyable/instructive
experience for
>> people to build something in Squeak?

You replied:
>Switching packages/points-of-view/"images" within the same image
without
>having to build a new image. 

Well, I think that building a new image to spec will become speedy and
simple given all the SqueakMap stuff getting built.
 
>And downloading packages without worry about
>conflict.  

If a new image becomes quick-n-easy to build, then conflict becomes no
big deal.  Do some quick diagnosis then build afresh! Also I would
rather diagnose package conflicts here then in a multi-namespace image.


>Also, having multiple packages in the image available for
>analysis, that would be conflicting in (A) and therefore not both
>visible.

I'm trying to imagine a sample scenario where running multiple package
releases in the same image would be helpful in development...  

Has anybody built a project where
Multi-Inheritance/Traits/Mini-Traits/Self/Slate has been super-helpful
to getting the thing working well ( i.e., Something like, "I'm working
on a ChristmasCarols package along with Pete and Sarah.  I'm trying to
analyze how different versions of the packages GregorianChant,
BaroqueChorale, and AcousticSpaces work together.  Here's how
MultiNamespace saved the day recently, when I tried to do ________ got
confused because _________ but was able to make all work gloriously
because _____________" ).  


Cheers,
Brent