I've been busy shrinking a 3.6(wx) image today. What a mess.

My definitive, permanent, and irreversible conclusion is that writing  
package unloading/shrinking methods is probably even a more senseless  
activity than clubbing seals or writing Java code.

I think that this is a very wrong way for moving towards a more managebly  
sized image. The community will probably take a couple of years to write,  
and maintain, package unload/discard methods (because the targets will be  
constantly changing - try any Removal method from SqueakMap and you'll see  
what I mean), and when there's a small image, at last, all that work can  
be, err, discarded. What a waste.

My suggestion for whatever version comes next:
- Take an existing 2Mb or so image (Edgar De Cleene has a 5429 image that  
includes MVC, tools, networking);
- Read the update stream since the image was made and filter out  
everything that doesn't apply to that image;
- Apply the rest;
- Publish what was applied and what not for review;
- Publish, test, and call that 3.x core.
- Have some people pledge to build distributions based on that image. I  
will happily work towards building a wxSqueak and a Seaside distro.
- Take it from there.

Personally, I fear that trying to strip something that doesn't want to be  
stripped will take a lot of time, waste a lot of energy, raise a lot of  
frustration, and will not have a better end result than following the  
route I propose above. That route will hurt a lot initially and will  
require a lot of politics etcetera to keep teams from forking based on the  
old stuff (but at the moment, risks that people will fork out of  
frustration are just as big). But that will be done in maybe 6 months and  
then we can direct our energy towards actually doing useful stuff (better  
dependencies, universes, bringing in Traits, and for some die-hard 'Core  
Squeak' believers, tearing down even that 2Mb image).