One problem I've had when doing this is that strict no longer provides protection against a typo in the variable name. At least by using an import you are making the name available unqualified at compile-time so that perl can check it for you.

use Foo;
print $Foo::fooo; # woops!
[download]

One argument for using a fully qualified name is that you prevent a name clash with a variable in the current scope, although I would consider it bad style to reuse a variable name in two scopes, where it is used in both and from both. It would also indicate to me that the variable has perhaps been badly named.

As usual it depends on the situation, but you need to be aware of the pitfalls of the approach you take. One module which uses package globals to modify its behaviour is Data::Dumper, which has variables such as Purity and Terse. These have quite common names, but you wouldn't want to export them into the current package because they are only used by the Data::Dumper code.

Data::Dumper on the other hand does have a more 'modern' interface to the same functions by using an object to store the settings which has the advantage of allows different callers to use different options.

--
integral, resident of freenode's #perl

I'm not sure I understand. Perl can indeed check variable names at compile time, even if they're fully qualified. Create a file called Foo.pm:

package Foo;

use vars qw( $foo );

$foo = 1;
[download]

Use it within a test program like so:

#!/usr/bin/perl -w

use strict;
use Foo;

print "$Foo::foo\n";
print "$Foo::fooo\n";
[download]

This gives me:

Name "Foo::fooo" used only once: possible typo at usefoo.pl line 7.
1
Use of uninitialized value in concatenation (.) or string at usefoo.pl
+ line 7.
[download]

I forgot about warnings. Sometimes they can be easily missed (I certainly have), so reading the 'Fatal Warnings' section of perllexwarn may be an idea.

use warnings FATAL => qw(all);
[download]

--
integral, resident of freenode's #perl