|The stupid question is the question not asked|
Unfortunately, I don't have time to address every point of your review, since I'm sitting in an airport and will need to leave soon. Let me address some of the more critical aspects:
The version number is 0.90 because the internal release at the customer site is 0.85, because they're already using it in their production and putting something like "0.15" into production would have been a bit embarassing. But to me, it does feel like about a 0.35 release, if that helps.
To acknowledge prior art would be to acknowledge every MVC framework I've seen. I didn't look at just one package. I've looked at dozens. This is not the heir apparent to CGI::Application any more than it's the descendant of Smalltalk's MVC pattern from my studies in 1981.
For said client, I was initially steered towards CGI::Application, and started liking the externals, but then was also told to stare at the internals and I'm glad I did. Huge subroutines covering hundreds of lines of code. And not quite the right callbacks that I needed, which would have meant a careful understanding of those monolithic subroutines to cut and paste, not just override callouts for callbacks.
What I did for the design of CGI::Prototype was Keep It Simple. Very Simple. No subroutine is longer than a dozen lines. Plenty of places to override all the built-in decisions. And yes, I went with Template Toolkit, because I hate HTML::Template, because I hate angle bracket languages in general for human editing. However, overriding engine and render would be trivial to use HTML::Template. I just don't describe it because I don't want to waste time encouraging it.
The way you design CGI apps is probably just another style that CGI::Prototype would need a different skin for. The "one page is one class is one file" is a specialization of CGI::Prototype::Hidden that happened to work for the three projects in which I'm currently developing. But I predict that other specializations are also possible for other styles.
So, in conclusion, I'm not rewriting CGI::Application. I'm designing a generic controller for use with CGI applications that encourages subclassing as a means of specialization. That hasn't been done yet (CGI::Application doesn't qualify, because it's too specific and not tweakable enough). I'm also developing applications with this framework and will probably continue to add other specific subclasses for other styles. Maybe even a CGI::Application compatibility layer, for example, as well as an Apache::MVC compatibility layer.
Your review presumes some things about the purpose of CGI::Prototype that are inappropriate. I'll take the blame for not communicating that more clearly. But many of the people I've shown are excited by some of the potential of this module. So I'll take that as positive feedback, and move on.