IMO source filters are a bad idea. My choices for resolving this in an external module would be (in order of preference):

use Some::Very::Long::And::Annoying::Package::Name;

use constant SVLAAPN=>'Some::Very::Long::And::Annoying::Package::Name'
+;
push @SVLAAPN::ISA,'Some::Very::Long::And::Annoying::Package::Name';

my $o=SVLAAPN->new();
[download]

Its unlikely I would use the stash approach as that just gives me the heebie-jeebies.

But this comes to an interesting point. An author of such an annoying package can easily provide the alias themselves... Ie in perl/site/lib/Some/Very/Long/And/Annoying/Package/Name.pm the author could have easily put

package SVLAAPN;
...
[download]

IOW, the package contained in a file that is used need _not_ be the same as the filename would indicate. A good and common example is Carp::Heavy. There is in fact no such thing. The file perl/lib/Carp/Heavy.pm contains only code for the package Carp. Now this might not be the best example as Carp/Heavy.pm is a behind the scenes kinda thing, but it does illustrate the point nicely.

In short while this is groovy and cool looking, it isn't perl (really), and it doesnt belong in production code. Nor do I think there is much need for this type of thing. The problem doesnt arise much and it only takes a few lines of code to sort out when it does. So IMO, this is a bit of overkill.