I don't recall having actually discussed your "move use strict" idea before. For this code, would it look something like this?

package Fred;

require Exporter;
@ISA = qw( Exportor );
$VERSION = 1.01;

%EXPORT_TAGS = ( 'all' => [ qw( ) ] );
@EXPORT_OK = ( @{ $EXPORT_TAG{'all'} } );

my %METHODS = (
  foo => 'bar',
  bo  => 'baz',
);

@EXPORT = (keys %METHOD);

use strict;

foreach my $method (keys %METHODS) {
    *$method = sub {
        return $METHODS{ $method };
    };
}

die "Use of ", __PACKAGE__, " (v$VERSION) not supported.\n"
    if  ! prerequisites();

1;
[download]

I guess your idea might make sense if you only ever mention each variable exactly once (the "standard" variables appear to be exempt from the "used only once" warning, so there is one more thing to worry about if you try this trick when you need any nonstandard package variables). But I still don't consider it a sound design as it is too easy to imagine future changes resulting in some of the variables actually being used within the package.

And if you use the variable as part of a standard initialization (above the use strict), then your typos are not caught. If you use the variable below the use strict, then you get a fatal compile-time error.

Note that I did suggest just removing the BEGIN block before I mentioned my personal preference, which I find makes things more robust in the face of several kinds of stupid mistakes. Not that I want to encourage such mistakes. It is just that the failure modes of those mistakes don't clearly point a finger at the mistake. Otherwise I think I'd stop that habit.

Obviously I wouldn't advocate obvious mistakes. For this code my preference would look something like this:

package Example;
use Exporter;
@ISA = 'Exporter';
$VERSION = 1.02;

use strict;
use vars qw(@EXPORT_OK);

my %METHODS = (
  foo => 'bar',
  bo  => 'baz',
);

@EXPORT_OK = (keys %METHODS);

foreach my $method (keys %METHODS) {
  no strict 'refs';
  *$method = sub {
    return $METHODS{ $method };
  };
}

1;
[download]

Move strict after all bog standard headers, but leave it before any complex logic. And, of course, where you need to, remove it. In this case 2 of 3 variables didn't need to be declared.

As for your objection about needing to use it, if you actually need to use it (as here) then of course it goes into a vars. But I find that 90% of the time the standard variables that you need for inheritance, Exporter, and versioning really shouldn't appear a second time. I see no need to spend effort making it possible unless I need to. And note the detail that if you have a typo on these standard variables, then warnings will catch it. So spelling isn't an issue.

As for the stupid mistakes that you refer to, we went through that before and there was not one you could find that I agreed on. Basically my attitude is that if you get in the habit of not playing unnecessarily cute games, then those mistakes don't happen. Plus your games wind up confusing other tools, like Carp. Trying to counteract one trick with another is something that I prefer to avoid.

You should check your assertion that mispellings of the standard variables will be caught by warnings when you play your latest "cute game". q-: Some will, some won't. See my example if you need specific ideas. ;)

I meant to add that I can understand not wanting to worry about such stupid mistakes. I didn't want to rehash the argument. (:

        - tye (but my friends call me "Tye")