My understanding is that the reference is to the value, not the variable.

You are demonstrating that, like "value", the term "variable" is not uniquely defined. There are more than 2 levels of abstraction and "value" is typically used for several of the lower layers and "variable" for several of the upper layers. Context often further clarifies which layer(s) are being discussed and many discussions are simultaneously valid when applied to more than one layer so the layer often doesn't need to be precisely defined.

But you are assigning the term "value" to a layer of abstraction that is, IME, much more commonly referred to as "variable". If "variable" only applied to the name, then we'd never need to use the term "variable name".

And we'd never talk in Perl of "anonymous variables". Such is more often spelled "anonymous array" or "anonymous hash". But "anonymous array variable" makes more sense than "anonymous array value" because an anonymous array is, in fact, variable (and thus should be considered "a variable"). You can push to an anonymous array:

push @{ ['anonymous','array'] }, 'variable';
[download]

If I throw in a named scalar variable to hold a reference to that anonymous array, then I could even keep the anonymous array around in order to demonstrate that its list of values has varied:

my $aRef= [ 'anonymous', 'array' ];
print "@$aRef\n";
push @$aRef, 'variable';
print "@$aRef\n";
[download]

Not that I object to the term "anonymous array value". But, to me, it just means that you are using an anonymous array variable in a way where you only care about the value.

A symbolic reference is to a variable by name or "a reference to a variable name" (and which underlying variable is referenced can thus change). Real references are references to the variable underlying zero or more variable names.

Here is a list of lots of layers of abstraction as examples:

3, the (numeric) concept (anything that == 3)

my $x= 3; my $y= '3.0';
print '$x and $y have the same value'
    if  $x == $y;  # read "if" as "because"
[download]

"3", the string (anything that eq "3")

my $x= 3;
my $y= "3";
print '$x and $y have the same value'
    if  $x eq $y;
[download]

3 as an IV

Any 4 (or 8) bytes containing the local 2's complement representation of 3.

my $x= 3;
my $y= pack "j", 3;
[download]

The IV part of $x and the string buffer of $y each contain the same value (and in the same format, but stored quite differently in terms of how you can access them).

a scalar value (conceptual)

my $x= 3;
my $y= 3;
my $z= "$y";
[download]

In most contexts, it is valid to assert that $x, $y, and $z all contain the same "scalar value" (or, of course, just "the same value"). This "conceptual scalar value" should be the default abstraction layer that one starts at when seeing "value" used in a Perl-related conversation. In most conceptual situations, the slight differences don't matter. This goes hand-in-hand with the fact that in most Perl coding situations, the slight difference also don't matter. That was the design goal, IMHO.

an SV (contents)

Depending on context, you might get away with saying "$x and $y represent two SVs that are the same" or "$x and $z represent two SVs that are the same" (using the $x, $y, and $z from the prior layer description). You are more likely to be corrected if you try to say "$y and $z represent two SVs that are the same".

In some ways, this is a particularly messy abstraction layer, IMHO. There are a lot of things stored in a perl SV struct (actually, the term "SV" is used to refer to a whole family of different C 'struct's). If somebody resorts to this abstraction layer, then they are likely just trying to point out some subtle difference between the implementation of two scalar values without getting bogged down in the specific struct member names or specific bits involved.

Actually, I think this abstraction layer is more likely to be used to say "$x and $y contain very similar scalar values but their SVs contain differences".

In case you were wondering, at a (relatively) high level, the main differences between $x's, $y's, and $z's SVs are: $y's only contains an IV (integer), $z's only contains a PV (string), and $x's contains both an IV and a PV.

Note how $x's SV was changed merely by copying the stringification of $x's value into $z. In most contexts, you don't consider that $x's value changed when my $z= "$x"; was run. You have to get deep enough to be worrying about what are mostly implementation details for this change to $x's SV to matter. I say "mostly" because there are relatively rare practical situations where such details can matter (such as when computing $x | $y).

an SV (instance)

use vars qw< $x >;
my $y;
*x= \$y;
[download]

Now $x and $y represent the same SV. They refer to the same SV (but they aren't what we normally call "references" in Perl, so this phrasing should be clarified when it can't be avoided).

The best term for this abstraction layer is "aliases". $x and $y are aliases of/for/to the same variable (or of/for/to the same SV). You usually create aliases by calling a function or using for, map, or grep.

This is the point at which we switch from "values" to "variables".

a variable

use vars qw< $x >;
{
    my $x= 'one';
    *x= \$x;
    for my $x (  $x  ) {
       $x= 'two';
    }
}
print $x;
[download]

The above code uses three different variables. All three variables are named $x. All three variables end up being aliases to the same SV. But each of the three variables have different scopes and different life times.

a variable instance

sub blog {
    my( $x )= @_;
    print "\$x = $x\n";
    if(  $x  ) {
        blog( $x - 1 );
        print "\$x still $x\n"
    }
}
blog( 1 );
__END__
$x = 1
$x = 0
$x still 1
[download]

The above code uses one lexical variable, $x. But since the scope where that variable is declared gets entered more than once, we end up with multiple instances of that lexical variable. You could also get away with talking about this code using two different variables, both named $x, at least in some situations.

a variable name

use vars qw< $x >;
$x= 'glo';
{
    my $x= 'lex';
    my $y= 'x';
    print $$y;          # 'glo'
    print eval '$'.$y;  # 'lex'
}
[download]

When we consider list values and list variables, we add more possible abstraction layers (some of which are even less important). Similarly, when talking about Perl references, there are a few more possible abstraction layers.

Most of the abstraction layers I listed above will be referred to simply as either "value" or "variable" with no further explicit clarification in a lot of conversations. We don't coin separate words to uniquely label each abstraction layer. Most of the abstraction layers aren't important enough to do such for them.

Note that insisting that "value" or "variable" can only be validly used to refer to just one specific abstraction layer is a pretty silly proposition (and just leads to not understanding people and documentation and not being understood by people).

And not all concepts even need nouns. Coining a new noun does no good for those who haven't read one's manifesto where one coined it.

So rather than conducting a poll on what noun to use for "the value of the address stored in a Perl reference that indicates which variable the reference refers to", just say "$x and $y refer to the same variable" (or a negated version, if appropriate). That way you'll actually be understood and won't have to keep rehashing the coining process in order to try to get each new person to understand your coined noun.

This is as bad an idea as talking about "the second transitus" (or whatever was recently proposed in another thread) instead of "the passed-in subdirectory name".