Yes, very much like the instance home. Jim was just asking about how that and setuptools would interact recently as well, and Phillip was talking about local plugin directories, and I realized site-packages was just becoming a global plugin directory, and that this global plugin directory cause me nothing but pain. So figuring out how to use setuptools with Zope instance homes, and then how this interacts with plugins and development and other use cases, could lead to a much more pleasant experience for everyone.
One of the issues with the Zope instance home is that Zope "owns" the home, more or less. It specifically is not part of the home. But every other piece of software is part of it. But there are many situations where no one piece owns the working set of packages, it is something more abstract. But if you install a command-line tool, I would expect it to be contained by the home similarly to how anything else might be contained. But if you are installing a web application that uses Paste, I would expect PasteScript (and the paster command) to be part of that same home, and not have a home of its own.
So I think these instance homes -- or "working sets" -- need to be more abstract than belonging to any one product. For some packages -- Zope being notably large (nay, absolutely huge) -- you also don't literally want a complete copy of the package in each instance home. So we have to consider how these can be centrally managed in some fashion. I think setuptools .egg-link provides the tool for saving disk space. The reporting tools to manage all the links and instance homes are still a big deal, and don't exist yet.
+1 on the idea of INSTANCE_HOME. However, I think you do want a globally-installed executable that "owns" the instance. Think of the instance as a word processing document, and the executable as your word processor. Files and applications, man. The zen is in defining a generic-yet-coherent problem domain for the application: word processing, spreadsheets, presentations.
httpy hits the generic-yet-coherent sweet spot for the "website" problem domain. The httpy executable "owns" an instance. Instances can contain multiple sub-apps, each with their own libraries located in situ. So, for example, a single site could integrate a CMS written with Zope 3, a Roundup issue tracker, and a custom contact form, let's say. You also get sitewide in- and outbound hooks for centralized security, templating, etc.
Full docs at http://www.zetadev.com/software/httpy/.
"[Y]ou also don't literally want a complete copy of the package in each instance home."
Why not? Disk space is definitely not the limiting reagent.