But = has slightly higher precedence than , so that second example is really parsing as if parenthesized ( $result = 3 ), 2, 1; rather than $result = LIST (and you can get the same behavior out of both the sub call and the scalar assignment by explicitly parenthesizing it as $result = ( 3, 2, 1 );). I don't think that disproves anything . . .

Update: using B::Deparse shows the differences:

$ perl -MO=Deparse,-p,-q <<'EOT'
sub return_list { return 3, 2, 1 }

my $result = return_list();
print "$result\n";

$result = 3, 2, 1;
print "$result\n";

$result = ( 3, 2, 1 );
print "$result\n";
EOT
sub return_list {
    return(3, 2, 1);
}
(my $result = return_list());
print(($result . "\n"));
(($result = 3), '???', '???');
print(($result . "\n"));
($result = ('???', '???', 1));
print(($result . "\n"));
- syntax OK
[download]

Update: Tweaked wording in parenthesized phrase slightly to hopefully make it clearer what I was referring to. I definitely agree it's a tricky case, but I'd say the problem is more "Everything that looks to the eye like a LIST in scalar context isn't" than a case where a LIST in scalar context isn't the value of the final element.

I don't think that disproves anything . . .

Parentheses don't make lists, though. Commas do. I agree that the higher precedence of the assignment operator is important, but it's very much not the case that all evaluation of lists in scalar context returns the final element of the list.

The statement $result = 3, 2, 1 is a LIST in void context with the list consisting of an assignment expression ($result = 3) and two constants:

$ perl -MO=Concise -e '$result = 3, 2, 1;'
8  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v ->3
7     <@> list vK ->8
3        <0> pushmark v ->4
6        <2> sassign vKS/2 ->7
4           <$> const(IV 3) s ->5
-           <1> ex-rv2sv sKRM*/1 ->6
5              <$> gvsv(*result) s ->6
-        <0> ex-const v ->-
-        <0> ex-const v ->7
[download]

Were one to evaluate this entire list expression in scalar context (say $outer = ( $result = 3, 2, 1 );, again only using parentheses for precedence disambiguation) the value in $outer would still be the last element of the list (1). It just so happens in the original that the entire list is in void context so it doesn't matter and that value gets dropped on the floor.

Having said that, I don't think displaying a value set as a side effect of one subexpression of building the entire list shows anything about the value of that entire list were the entire list in a scalar context.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Are you thinking of some counter-example? I have the feeling that would involve a definition of list different than mine.