in reply to use Very::Long::Module::Name as Foo;
In terms of complexity to use, all of the proposed solutions, including yours, are about equal. In terms of conceptual difficulty for a Perl programmer to figure out how they work under the hood, yours is significantly more complicated. In terms of avoiding possible conflicts between different modules making use of the feature, I prefer either putting the package name in a variable or a constant to anything that tramples over short global namespaces that other modules don't expect you to trample over.
Also I like reserving source filtering for when it really buys a lot because I am afraid that, going forward, we will wind up with "interesting conflicts" because different source filters won't cooperate well with each other. (The heuristics which one uses to figure out what is going on don't take into account how the previous one altered Perl.) Traditional Perl modules have much lower odds of conflict.
In fact a private theory of mine holds that one of the keys to what made CPAN work is that Perl didn't used to lend itself to customization, so code that worked for you probably works without many issues in my environment, and vice versa. This makes sharing easy. Compare, say, to a significant body of C code with heavy use of pre-processor definitions.