I can see merlyns point to some degree, however I've not used Moose (and have no immediate plans so to do) but surely, implementing CGI::Prototype as you suggest would introduce previously unneeded dependencies, on the part of existing code, on Moose i.e. removing any backward compatibility ...

Upgrading to the use of Moose would wreck backwards compatibility with any previous CGI::Prototype apps. However, note that you say: "implementing CGI::Prototype as you suggest". merlyn has no issue with Moose for a newer CGIP. He has an issue with standard Moose. So either of our approaches to adding Moose would cause this problem.

or have I, not for the first time, missed something otherwise obvious ?

The issue would be what new apps would run on. And, assuming that the new module with the new implementation is named something other than CGI::Prototype, then new code would simply use this different as its base class.

Surely you should be reserving/creating a new namespace e.g. CGI::Prototype::Moose, to make the provenance abundantly clear to all and sundry - in a manner that the namespace CGI::Class doesn't.

Well, initially I wrote such a module and planned for it to be part of the standard CGIP distro. But merlyn has made it clear that any standard Moose CGIP will not be in the CGIP distro, hence the name change.

I think using CGI::Prototype::Moose would make him uncomfortable and I certainly dont intend to narrow my approach to Moose forever. There were class-based OO before Moose and may be afterwards (though I doubt it).

Moose is the current chosen object layer for a class-based implementation of CGI::Prototype. I dont think the object layer itself need be in the module name. For instance both Catalyst and DBIx::Class are being re-implemented in Moose but retaining their current name. Likewise, I have a number of modules on CPAN that use Moose (e.g., Number::Closest) but the dont have Moose in their name.

Should Class::DBI have been named Class::DBI::Accessor::Fast?