To pick a nit, I think the problem is that they are not aliases, not that they are not lvalues.

From a Perl delta POD:

perldelta - what's new for perl v5.6.0

[...]

=item delete(), values() and C<\(%h)> operate on aliases to values, not copies

delete(), each(), values() and hashes in a list context return the actual values in the hash, instead of copies (as they used to in earlier versions). Typical idioms for using these constructs copy the returned values, but this can make a significant difference when creating references to the returned values. Keys in the hash are still returned as copies when iterating on a hash.

See also L</"delete(), each(), values() and hash iteration are faster">.

For example:

require Tie::Hash;
use vars qw( %h %t );
%h = ( a=>1 );
tie %t, 'Tie::StdHash';
%t = ( z=>9 );
eval { sub { values %h }->() += 10; };
warn "$@\n";
eval { sub { values %t }->() += 10; };
warn "$@\n";
print ref(\substr("hello",1,2)), $/;
print ref(\sub { values %h }->()), $/;
print $/;

use vars qw( $a, $b, $c, $x, $y, $z );
print $a=\values %h, $/;
print $b=\values %h, $/;
print $c=\sub{values %h}->(), $/;
print $/;
print $x=\values %t, $/;
print $y=\values %t, $/;
print $z=\sub{values %t}->(), $/;

print $/;
$,= " ";
$$x= 31;
print $$x, $$y, values %t, $/;
$$y= 32;
print $$x, $$y, values %t, $/;
$$x= 33;
print $$x, $$y, values %t, $/;
__END__
Can't modify non-lvalue subroutine call at values2.pl line 6.

Can't modify non-lvalue subroutine call at values2.pl line 8.

LVALUE
SCALAR

SCALAR(0x1a7f228)
SCALAR(0x1a7f228)
SCALAR(0x1aced54)

SCALAR(0x1aced60)
SCALAR(0x1aced78)
SCALAR(0x1aced9c)

31 31 31
31 32 32
33 32 33
[download]

I expected the last three references to all report the same address (showing that they are aliases) while the three above that wouldn't. In fact, this shows that the "aliasness" is not preserved in the tied case either but that Perl does some extra magic (that looks a lot like lvalueness but not quite) in order to make the results from values for tied hashes behave like aliases.

Seeing this, I tested this magic some more with the last code, which looks like we have two separate scalars that each have magic telling them to update the tied hash if they are modified.

But return @list isn't documented to return aliases to the values in @list so it is free to copy @list instead, so I don't think this is a bug. The enthusasism of the magic values returned by values on tied hashes is a bit surprising to me, but I'd need to dig a lot deeper before deciding if a change is warrented there.