I think one of the problems with Zupal is that I started at the domain end instead of looking into the hook system which is at the heart of Drupal.

The hook system is essentially the observer pattern externalized. But to some extent it is lopsy because the event system was applied incompletely. That is: the mechanisms that Drupal itself runs on are not hooks but are task solving PHP blocks.

That is one of the reasons that people still have to write modules in PHP.

So, what if we incorporated an event structure into the internal workings of Drupal/Zupal and made it wholly event driven? that is, everything from saving a record to creating a form revolved around the same hook / observer system?

What this means is that your entire systems architecture could be built up, semantically, around a single architectural element. That is, EVERYTHING -- forms, templates, config settings -- extends from a basic Data class which can be stored in the database and/or JSON, journaled, and created and maintained using a singular administrative interface.

The hook system then becomes a messaging system between data. The URL goes through the routing system, triggers a resolution data item to be loaded, and it cascades calls throughout the data network to resolve the call into a visible (HTML generally) artifact.

Starting from this architecture you could really build not only any website but practically any other software artifact you feel like. You would get the benefits of the Drupal architecture -- open and semantic data mapping, decoratable views and forms, etc., which would extend from the basic elements as needed. The implementing code would exist in class files generated to handle the operations of the interfaces using classic OOP and the whole system becomes extremely "Design by contract".

The DataSource interface, being responsible for tactical I/O, could be wrapped around any ORM. The View system could adapt to an existing templating engine, or core PHP. The form engine would probably have to be custom and intrinsic to the Zupal engine, as would theming and display blocks.

Using this semantically driven architecture you can accomlish just about anything -- and definately the architectural wins of Drupal.

First Source

I have got the basic event system and data model fleshed out. Some emergent patterns: 

• In order to more intelligently filter event handling, listeners are added with a target type; this can be a class or interface name -- if the target doesn't belong to/implement one of the listed interfaces, the messages pass on.
• The first data source worked out is a JSON source system.
• the source model has been factored to work only with raw values -- keys and field arrays. This keeps the source extremely specialized to I/O: it is the Model that concerns itself with the OOP layer. This means that much lighter/faster data management can focus on source level transactions.
• The first set of events to be listened to are save and delete events in the model.
• Right now, fields are only nominally data -- this prevents recursive mindf**ks like what are the fields' fields, though at some point that might become useful. 
• I am using Zend Framework for some very utilitarian stuff (JSON parsing, data gateway). It is not bundled with this package -- see references to ZEND_PATH.

This source is still being worked through -- it is not completely functional, though the event model seems validated. Becuase the system is purely file-based, it basically works out of the box, once you have set your own value for ZEND_PATH. It is currently NOT in svn/GIT.