Ugh, I'm sorry, but having each application install its own version of common libraries in its own location sounds to me like a maintenance nightmare. What happens if there's a security bug in an underlying module which makes it necessary for you to upgrade it? You then have two options:

1. Find every instance of that module and update it in place, making sure that you break none of the applications in the process.
2. Wait for all applications to release a new version with the upgraded module, which can take days to months, leaving you vulnerable in the meantime.

Both of these are extremely nasty. Additionally, encouraging the practice of using "private" versions of modules will lead to brittle applications which assume they know exactly which kind of environment they're working in, as well as a plethora of "tweaked" versions of modules for each app.

The CPAN way works extremely well for the two more common usage scenarios, that of a multi-user machine maintained by a (team of) admins whose responsibility it is to check that upgrades do not break apps (this can be helped a lot by using an OS/distribution which does sane dependency checking and provides clean upgrades for the included packages), and that of a single-user machine where the admin is also the developer/user. It does not work quite so well (as you have illustrated) for the shared web hosting environment where untrusted users need to install their own modules. Frankly, I don't consider that usage scenario important enough to make things harder for the rest of us. Maybe some specialized applications which are most commonly used in webhosting environments could go this way, but I'd recommend against making this common practice.

As an addendum, there is a single PHP web app I use, and I run multiple instances of it. Every time a security-related bug is discovered somewhere in the package I need to upgrade each and every instance of the app instead of just one underlying library, which pisses me off no end.