First off: Cool. I've not seen anyone really talk about this, and I think it's important.

That said, you can always look at the series of "pages" users will view as a state machine. The only difference between your two implementations is how you define the state transition rules.

Even a traditional flat HTML website - current state is stored in the user's browser (what URL they are on) and transition rules are in the form of href's.

Disclaimer: I've not looked at CGI::Application. I've looked at Everything, but not used it.

Obviously, different approaches will work best on different sites. My worry about Everything is that for a high traffic website, the db will be the bottleneck. databases don't scale nearly as well as webservers (especially when you can just add more webservers to the farm). For a low/medium traffic site it probably doesn't matter at all.

Out of curiosity, why rule out the traditional "collection of CGI's" method? It keeps transition information local to the individual files (you might have 1 CGI that did the entry/validation/success, 1 for change password, 1 for edit/preview/submit, etc), doesn't store it in the db (so the db can do more important things - like storing content), and has a fairly short learning curve. Is your site intended to just be too dynamic (changing structure all the time)?