Dependencies and RPM hell, revisited - time for a fork?

Those of you who participated in the long and repititive "dependency
hell" / "packaging hell" / "RPM hell" discussions earlier on this
list may be interested to the "ultimate solution" I've worked out:

http://greenrd.org/hetero/archives/2003_10_01_index.html#106581990421373254

It may seem wildly over the top to suggest that packaging problems
are a good reason to fork a new OS. But I think it is a good excuse,
at least, to have some fun and experiment with different ways of
doing things. My packaging solution necessitates getting rid of the
standard /bin /usr /var hierarchy, and once you've taken a "radical"
step like that you might as well go further and make some more
"controversial" changes that the likes of RedHat would be unlikely
to accept as patches.

[Incidentally, the DragonflyBSD project - also a fork of a popular 
alternative OS - have come to a similar conclusion to me, that
automatic "multiple versions installed" support is needed for
package managers - but the way they've chosen to implement that
is slightly different.]

There's no point in starting from scratch - the Linux
kernel, especially 2.6, has hundreds of man-years worth of hardware
support and tuning in it, which is priceless. But certainly some of
the userspace stuff, like RPM, could be completely replaced with
better systems and subsystems.

Anyway, I would suggest any replies to this be posted on my blog,
instead of here, because they are likely to be offtopic here.

-- 
Robin