If you believe what I wrote in The "Guess the Version" Game, there's no completely reliable way to determine the appropriate version of the Perl 5 language which applies to a given file. You can use a static analysis tool such as Perl::MinimumVersion to give you a best guess based on a set of heuristics... but that's possible to fool.
Unlike Perl 5 static parsing, where only a malicious developer would write the maintenance-nightmare code that foils a smart static analysis tool, it's reasonably easy to imagine that a well-meaning and maintenance-savvy developer might write code that fools the language version checker. After all, keywords like
err make a lot of sense as keywords because they describe concepts effectively and efficiently. There's little difference between choosing good keywords and good symbols for identifiers.
There's only one good way to specify the intended version of the Perl 5 language in use in any given source code:
package SecretMonkey::Utilities; use 5.010; ...
If you want to future-proof your code against future language changes, document your assumptions. (Note that well-packaged CPAN distributions have had this policy for years. It's not a new idea; it's a good idea unevenly distributed.)
If Perl 5 had adopted this policy a decade ago (or, better, even earlier!), we could avoid a lot of current problems with the debate between making new features available by default or being as compatible with Perl 5.000 as possible by default.
perl can't assume anything about the features used or not used within a particular file -- especially new keywords -- because it doesn't know which version of the language to use to parse the code.
Any new Perl 5 code written after this point which lacks a language version specifier in every file carries a very preventable maintenance risk. You don't have to use Perl 5.10.x (though you should), but you should specify the version of the language you expect.