Sorry, I'm lost. Either I'm not understanding you, or you're not understanding me, or most likely both :)

The function ref is used to determine if its argument is a reference: if ref returns a true value, then its argument is a reference to something, right?

As an added bonus, it tells you what that reference is referring to. Therefore the following code makes everyone happy, right?

#!perl -l
my $s = "foo";        # a scalar
print ref($s);        # prints nothing: $s is a scalar, not a ref
my $sr = \$s;         # a reference to a scalar
print ref($sr);       # prints SCALAR
my %h;                # a hash
print ref(%h);        # prints nothing: %h is a hash, not a ref
my $hr = \%h;         # a reference to a hash
print ref($hr);       # prints HASH
my $hrr = \$hr;       # a reference to a reference to a hash
print ref($hrr);      # prints REF
[download]

So the precise meaning of REF is "a reference to a reference (to anything - sorry, it only goes one level deep)"

Fine; where would you find this useful? (Viz, with added value over SCALAR, which up till today I'd have interpreted as "(reference to) a scalar value, which might be a number, a string, or a reference" (inclusive or here).

My problem arises from a seeming inconsistency of the concept "scalar" in Perl. In the guts, there are IVs and NVs and PVs and RVs; but the user just wants his $scalar, with all these possible values conflated. I'd venture to say that this conflation is a widely accepted feature by Perl programmers. Note how another, well-known breach of this generalization — you can't use references as hash keys — is often regarded as suprising (and frustrating) behavior the first time someone encounters it (I think!). Certainly from the user perspective, of the Perl language, it isn't a useful feature, but presumably it makes more sense from the implementation, perl, point of view.

So is ref returning REF on \\"moose" just some leftover hairiness? Or is there a nice hack waiting to be found here?

another, well-known breach of this generalization — you can't use references as hash keys

This is a different issue. Hash keys are not scalar values, they are string values. It happens that, very often, the stringified value is the same as the useful scalar value. In some cases, though, this is not true. References are one example, but another would be a variable with a dual value. Consider the following example:

    open "non_existent_file";
    print $!+0, ": ", $!;
    $hash{$!}++;
    for (keys %hash) {
      print $_+0, ": ", $_;
    }
[download]

Which outputs the following:

    2: No such file or directory
    0: No such file or directory
[download]

The separate numerical value is lost, because the value is stringified as the hash key, not stored as an arbitrary scalar.

perl -l
*r = ["goose"];
*r = \"moose";
print ref \*r;
print ${*r};
print @{*r};
__END__
GLOB
moose
goose
[download]

So you see, GLOB is a useful value in this case. In anycase - if ref() returns a true value, THAT means there is something to dereference here.

Just to make it clear: ref($r) returns "REF" if $r is a reference to a reference.

On the other hand, I agree that the REF return value just adds unnesessary complexity and returning SCALAR for a ref-to-a-ref would have been more consistent and simpler (just like an arrayref returns ARRAY, and doesn't care about the elements of the array).

Certainly GLOB is a useful value. The purpose of the example was to show that REF is less useful than it would seem because it is not exhaustive. Other things -- GLOBs -- can also hold references, so when writing code that decides whether to recurse further you need to either match against multiple values or call ref again anyway.