Rik,
I had the exact same problem with a recent design. My very first design using ZClasses when they first came out, I put all classes in the root of my product. This made the management interface for "Folders" tough, but that was the only sacrifice really. (All those messy meta_types) But I used the "Subobjects" tab and made sure only certain objects could be added quite nicely to my other ZClasses.
Also the flexibility for extending this design was better that the one I laid out using "nested" ZClasses. It turned out that whatever level you nested a ZClass that was it's level of creation and inheritance. That was very tricky to design around.
I am now back to using my first method (all ZClassses under the product). But I recently discovered a bug that has been reported by Alexandre and a few others. If you don't subclass ObjectMangaer in your "Base" ZClasses, and you create subclasses off of you own non-ObjectManager Bases, they never show up in the management interface or any objectValues(), etc... Because I didn't do this, and it is bad juju to change the ZClass Base Classes, I have started to look into creating straight Python Products.
That's my experience and I hope it helps.
Thanks Jason, I already came to the conclusion that a 'flattened' design was probably the best option. Technically a python product is probably even better. I want to be this a web (read ZClasses) only, product so that it is easily customizable. Ease of management through the web and flexibilty are the main assets of the thing (in contrast to the existing commercial web educational packages). Therefore a ZClasses solution is the only way to go I think. By way of background: this is a product that is to be used for managing an educational site (containing a management layer, a design layer and a flexible web course layer). There are already a zillion methods and properties inside the product and I was reluctant to change it in fear both of breaking things and of getting behind in getting the damn thing out. But I think that is the only option (sigh). Thanks for your help and for thinking along, though. Rik