|Do you know where your variables are?|
You have disqualified yourself...
I'm sorry, I don't understand that sentence, care to explain what you mean here?
..."making sure you break none of the applications" is required step...whether you upgrade in one place or multiple places
Yes, but it's much harder, because you've got dog-knows how many different versions of the module installed for the different apps (that's the whole point of this scheme after all, right, to be able to have the version of a module which the app is written against) and you now have to find out what changes between each of those versions and the newly fixed one. Much, much harder. And yeah, finding the module file is easy enough, but then you have to care enough to upgrade the gazillion instances you have strewn all over your disk, and time being a scarce resource this will often not happen. This is a prime recipe for increasing the number of out-dated Perl modules installed on production machines and giving Perl a bad security rap.
I'm confused, if you can auto-generate the packages you're presuming that the bundle will work with the latest version of the module. So what's the difference to installing the latest module version into a central place? The only difference I can see is a false sense of security on the part of the user who thinks "this must work because I downloaded the Bundle" and will be all the more disappointed if it breaks.
..won't suddenly lose a clue about good software practices
Anything that gets made easier will be done more often. If module authors no longer need to care about their app working with the latest version of an underlying module version they will be tempted to use deprecated features, module internals etc., because "it works if you use the distribution". Other things (like adding the latest feature) will take precedence over robustness. That is part of my point, keeping different versions of modules on the same machine should be something that requires manual intervention, it's not good practice (most of the time) and you should have to think about what you're doing.
This attitude of not caring about end users
You misunderstand, I do care about the end user, and installation of a software package is indeed an important factor in its uptake (I've more than once refrained from trying out a Java app because of the horribly horrible horror that is Java installation and package handling). But Perl isn't a one-trick pony like PHP, it has applications that go far beyond the web-hosting sector. The requirements of all of these users needs to be taken into account when trying to improve some aspect of the language, not just of a relatively small subset of the user base.
If someone wants to use PHP instead of Perl (or Ruby or Python or any other language) and has good reasons for doing so, more power to them. To me the disadvantages of PHP are numerous enough that I'll prefer Perl any day, and one of these is the area of security. I care much more about Perl getting a bad reputation for its security than I care about the convenience of amateur webmasters (just to be clear, I'm not saying all users who use shared webhosting are amateurs, but those for whom this particular issue is a problem probably are).
I do agree that dependency handling an installation from CPAN is not as end-user friendly as it could be, but this is a very hard problem to solve correctly. I don't see any merit in auto-bundling software together for the purpose of spewing multiple versions of module all over your harddisk.
A computer is a state machine. Threads are for people who can't program state machines. -- Alan Cox