I've got a gut feeling for what we need, some of it resonates with what you post here, but I've personally grown sort of attached to Cocoon, so first off, I'd have to answer the subject line with a resounding "no".

What we really need?

- back end legacy connectors. I can do that with JBoss;

- 100% 24/7 rock solid transaction management and data persistence. I can do that with JBoss and some commercial (or maybe even OS) RDB;

- flexible data translation and extraction. I can do that with Saxon;

- involving, low error, client side interaction: I can do that with AJAX and the rest of the browser stuff that you mention.

So why do I want Cocoon (Java or similar glue is assumed)? Because I still need some sort of bridge from the first three things to the last.

I need a really efficient action dispatcher. In spite of the fact that many might feel that this is one of the weakest parts of Cocoon, this is what it does better than anything else:

client action -> map to handler -> run business rules -> persist results -> (begin again)

Eventually, I expect some form of generalized Ontology traversal (perhaps the semantic Web) to handle the second step

but darned if I see any real AI stepping up to handle the third step.

For the foreseeable future I need some kind of multi-technology mosh pit for that process to work in and currently that looks a lot like Cocoon.

that tells us where the real work is: object mapping, pattern recognition, etc (and the great bugbear; distributed cache management to keep the results fresh but yet responsive).

The client is starting to be able to talk to the humans, next we need a way for the server to truly understand what that interaction means, requires, and implies in a global sense.