I think that it is really a question of context. The built in variables that ambrus lists from perlvar are independent of which package namespace you are in. This is not the case with $AUTOLOAD. Conceivably there could be different $AUTOLOAD subs nested, and in different namespaces if one AUTOLOAD sub causes another one to be called (if it calls a non-existent sub elsewhere). Similarly, @ISA lives in package namespace and needs declaring with use vars or our.

Specifically, the $Foo::Bar::AUTOLOAD symbol table entry does not exist except when AUTOLOAD has been invoked (but &Foo::Bar::AUTOLOAD is the subroutine). The scalar is set up with an implicit local declaration, hence the entry is removed when you return out of the call frame.

In theory you could have nested calls to the same AUTOLOAD if the sub is itself invoking non-existent subs in the same namespace. But this is a very bizarre way of doing things.

Something the OP did not mention is that code to autogenerate the subroutine usually needs to turn off strict 'refs' in order to put the new sub into package name space. For example: (warning: untested)

package Foo::Bar;
use strict;
use vars qw/$AUTOLOAD/;

sub AUTOLOAD {
    my ($self) = @_;   #Don't use shift as we need to preserve @_

    my ($meth) = $AUTOLOAD =~ /(\w+)$/;

    # Simple example: getter and setter for hash members
    # Note that the eval is here to stop the sub becoming a closure on
+ $meth

    my $acc = eval qq( sub {
        my \$self = shift;
        \@_ ? \$self->{$meth}=shift : \$self->{$meth};
    } );

    {
        no strict 'refs';

        *$AUTOLOAD = $acc;
    }
    goto $acc;
}
[download]