I have seen a lot in this thread...about how perl should be extended, or managed, in order to make it a panacea for all that needs to be programmed.

I don't see this thread as suggesting that perl is the answer to every programming problem. I do see people wanting to use perl to solve some programming problems in an enterprise computing environment, and finding that some aspects of how it's packaged and its culture has evolved throw up some barriers to acceptance in that environment.

Implicitly, you're suggesting that these barriers are intrinsic to perl and that, essentially, it isn't an appropriate language in the enterprise--that's simply not perl's niche. I think the point is that there are enterprise programming tasks for which perl would be the right language, if only people could satisfy some of the traditional MIS concerns about introducing any new tool to the environment: packaging, administration, engineering process...

The question isn't, "Can we extend perl's syntax and modules so that every enterprise RPG/Cobol/Lisp/whatever program can be rewritten in perl?" It's, "Can perl's surrounding infrastructure be cleaned up a bit so that an enterprise programmer can choose to use perl when it's appropriate without scaring management and the IT department?"