I like the idea of seperating the GUI/protocol layer from the layer that does the work.

me, too. This should be done before any other thing concerning UI, e.g. skinnability. The question for me is how a possible solution would look like. Actually the model objects should be stored in ZODB then as they carry the data and the view/controller objects need to be retrieved from somewhere else..

Though this is a large project, it can still be done in small steps. The first step could be a policy that all core functionality should be in separate methods, without changing the class structure at first.

For example, OFS.Folder.manage_addFolder() both creates and adds a folder, and also returns the HTML for the main management screen. manage_addFolder() could be refactored to first call a _createFolder() method (implementing the core functionality), and then return the HTML. With no changes in API or class structure, such refactoring can proceed now, as no existing code that uses manage_addFolder() would be affected.

In addition, we'd quickly get useful core functionality methods such as _createFolder(), which would become the preferred way of creating folders from Python code.

Then, for Zope 3.0, you can do the big class restructuring of moving the HTML rendering out of the core Folder class. This in turn will be easier because you will have already separated out the functionality into different methods.