I'd like to avoid the situation where, for example, one of our modules is given an unfortunate name (like "Symbol"), and gets used (and causes problems) because we're in somebody's PERL5LIB.

So if I'm understanding you correctly, you want to avoid the following problem (sample case):

#!/usr/bin/perl

use IO::Handle;
print "OK\n";
[download]

Now, let's say you have a private module "Symbol.pm", which also happens to be used by IO::Handle.  So,

$ touch Symbol.pm

$ ./891005.pl
OK

$ PERL5LIB=. ./891005.pl
Symbol.pm did not return a true value at /usr/local/perl/5.12.2/lib/5.
+12.2/x86_64-linux-thread-multi/IO/Handle.pm line 264.
BEGIN failed--compilation aborted at /usr/local/perl/5.12.2/lib/5.12.2
+/x86_64-linux-thread-multi/IO/Handle.pm line 264.
Compilation failed in require at ./891005.pl line 3.
BEGIN failed--compilation aborted at ./891005.pl line 3.
[download]

(In the first case, IO::Handle loads the correct system version of Symbol.pm, while in the latter case, IO::Handle loads your private variant, because it's found first along the search paths.)

I'm not sure, however, how your approach would help here.  In other words, you'd get the exact same problem in case you had use lib "."; at the top of the script.

Of course, you could fiddle with the order of the use statements, but that seems very fragile, too (in more complex, real-world scenarios).  And if you want to go that route, I don't think there's really any way around having to carefully place boilerplate code in all of your modules...  IMHO, choosing an unambiguous namespace for your own code is the better option.

Or is it some other problem you're worried about?

I agree that my approach burns the users who execute my scripts, should somebody on my team create a Symbol.pm... However, what (I think) my approach avoids is the case that:

1. somebody sets up PERL5LIB to point to our libs, as a matter of course while setting up their day-to-day working environment (because they intend to run our scripts pretty regularly), and then
2. runs something that's got nothing to do with our scripts, and gets burned because our (badly-named) libraries take precedence

My boilerplate approach only hurts invocations of my scripts; the PERL5LIB approach hurts invocations of all scripts. Potentially.

I do like the idea of using a team-specific namespace... That seems clean, and enables me to leverage PERL5LIB. Thanks!

Don't require your users to set PERL5LIB themselves in order to run your scripts.  Set it yourself (locally for the process), in a wrapper script, or some such.  If they then still insist on pointing their PERL5LIB to your private libs in their day-to-day environment, it's their problem...

You could also write the wrapper such that it copies the contents of some other env variable (e.g. XX_ROOT) into PERL5LIB.  This way, they could make their choice by setting XX_ROOT without affecting anthing else, while you can still take advantage of PERL5LIB, to avoid littering use lib all over the place.

#!/bin/sh
export PERL5LIB=$XX_ROOT
exec ...
[download]

P.S.: Perl's -I command line option could be used similarly:

#!/bin/sh
exec perl -I$XX_ROOT ...
[download]

(you can only specify one directory per -I option, though)