No, if( $var => 2 ) { ... } is the same as if( $var, 2 ) { ... }, and a LIST in scalar context is the last element from the list. There's nothing undefined about it.

a LIST in scalar context is the last element from the list.

Not always:

sub return_list { return 3, 2, 1 }

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

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

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.

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