I haven't taken the time to look at your stuff, yet, but hope to this week. A bunch of us are really busy with OpenACS 4.x porting and development work at the moment.
In principle, this looks interesting. In practice, it will look a lot more interesting after OpenACS 4.x is released.
Since you're not at the production stage yet, and since we've not released OpenACS 4.x yet, a timely convergence of folks' having more time to poke around and explore your stuff and you're being satisfied with its status as production work seems possible.
We've already rewritten the OpenACS 4.x content repository to provide both in-RDBMS and in-filesystem storage, with a common API, so at this basic nuts-and-bolts level we're thinking somewhat in common. The 4.x content repository also provides some of the object management you mention - folders, etc - and our goal is to move all content into this framework. In particular this will simplify site wide searching, which should only have to search in one place, i.e. the content repository.
It should flatten the learning curve a bit, too - right now you need to learn how bboard uses its own custom repository, how certain other packages store content "by hand", and how "proper" packages use the content repository. Much of this is grotty and ad-hoc at the moment.
Despite this similarity of thinking, the approach taken by 4.x is totally different. The object model lives in the RDBMS, rather than in the Tcl layer. Your approach appears to be much closer to what aD is doing with their Java re-implementation. There's a lot that can be said about trying to pound the object model peg into the relational model hole, mostly negative things, so I'm not going to claim that the approach taken in 4.x is superior.
However, it's there and in the near-term, at least, we're stuck with it. So I have questions as to how well your work would meld with the current OpenACS 4.x object model. Have you looked into this at all?
