I like the variant of (2) that uses special locations in /usr/local for all CPAN installation. This sounds like the easiest way to cover any possible problems, and I suspect that CPAN.pm and CPANPLUS.pm already do this by default (see below).

Technique (1) on the other hand strikes me as very generally useful: it might be more work, but once you've mastered those techniques you'll find other uses for them (like, for example, you want to try upgrading from perl 5.8 to 5.10 for the production code, but leave 5.8 in use for the system code).

Technique (3) is very Debian/Ubuntu specific, and at a guess is only worth hassling with if you're interested in getting involved with helping the Debian project by maintaining debs of perl modules.

What I actually do, however, is ignore the problem: I install a bunch of debian/ubuntu perl packages, but whenever I'm so inclined I do installations and updates via CPAN.pm or CPANPLUS.pm. I realize it seems like living dangerously (how do I know an "apt-get upgrade" won't downgrade something important?) but I've yet to run into any difficulties like that.

Taking a look at my @INC, I see I've got a rough order of precedence of dev, local, and system locations. Maybe that's a policy that helps. I just experimented with installations via CPAN.pm and CPANPLUS.pm, and I see they both install in /usr/local/share -- it could be I've got method (2) covered already without realizing it. There's nothing special in my ~/.cpan/CPAN/MyConfig.pm that does this, so it would seem that CPAN.pm/CPANPLUS.pm do the Right Thing by default.

This is an experience I've been having lately with perl, by the way... I start worrying about some issue, dig into it, and I find that it's largely a non-issue because someone else did something intelligent a long time ago.