Ah here I definitely disagree - I think this is a huge landmine.

Whether people come to use a layered system for it's real benefits or
not, I think it would be a disaster if people use it to ignore trivial
incompatibilities between packages.

Remember that one of the great benefits of free software development is
the testing. It's a critical part of the magic. For a modular
environment, as Squeak is already headed to be since the day SqueakMap
is online, integration testing is a large part of the issue. 

Where two packages need significantly different functions, they should
be using two separate, mutually neutral actual mechanisms. Where two
packages need slightly different versions of the same thing, this needs
to be visible, slightly painful for all involved, until it is resolved. 

I'll give you a concrete example - if each package, as part of it's
layer, should bring in it's own version of the TWM>>openMenu, everything
would "work", and the user might go mad before understanding why it
keeps changing on him. The solution is to find these areas of conflict,
however small, and redesign them for cooperation. Not to apply a
one-size-fits-all plaster that allows all packages to ignore one
another.

The real solution is for package maintainers to avoid patching other
packages, in your package, instead submitting patches to the upstream
packages maintainer. And concurrently, to give the user tools to notice
and control when this is happening.

Daniel

> I do much the same thing as you do.  However, I wasn't thinking about 
> development images; my "mail" image might have other packages that help
> me use Squeak as a media environment (eg: Connectors).  These packages
> may be very well tested with the base image, but might step on each
> other's toes.  Even if things seem to work, I can't be sure that things
> won't explode later (without looking at all the methods in each add-on
> changeset to make sure that they don't appear in another add-on changeset).
> In other cases, the breakage might be immediate and evident. Environments 
> would address this problem.
> 
> Joshua