You misunderstand.

No, the list assigned to is not %return. You are taking a hash slice. The hash as a whole is nowhere to be seen in this assignment. I get the feeling that you haven't understood exactly what taking a slice does.

Yes, the list assigned to is on the left hand of the assignment operator.

I'm not sure which second code sample you are talking about.

You are not seeing the list assigned from. You are seeing what the list you assigned to evaluates to, which in this case is 1, 2, 3, 4. The distinction is subtle and may be confusing but you are indeed getting the list assigned to:

#!/usr/bin/perl
use strict;
use warnings;

use Data::Dumper;

my %return;
my @value = qw( foo bar baz quux );

$_ = uc $_
    for @return{ qw( a b c d ) } = @value;

print Dumper( \%return ), Dumper( \@value );

=begin output
$VAR1 = {
          'c' => 'BAZ',
          'a' => 'FOO',
          'b' => 'BAR',
          'd' => 'QUUX'
        };
$VAR1 = [
          'foo',
          'bar',
          'baz',
          'quux'
        ];
[download]

As you can see, the $_ = uc $_ assignment changed the values in the hash. If you were getting the list assigned from, it would have changed the values in @value.

Makeshifts last the longest.

I had considered trying to take this off-line, but if I am still confused, maybe others are.

My question is, why does the list assigned to not include the keys as well ?

And perhaps can you give an example that doesn't use $_ with all its aliasing behaviour just adding to the noise.

...it is better to be approximately right than precisely wrong. - Warren Buffet

The value of a line such as:

  $x = 1;
[download]

is 1. Obviously. But the reason it's one is not because $x is now set to 1. It's because the RHS is 1. Thus, if I do this:

  $x[0] = 1;
[download]

This too is 1. Not @x.

Hope this helps.

What does this print?

print join ' ', @return{ @keys };
[download]

Why would an assignment behave differently? And if it should include the keys, then what should happen if you said this?

( $foo, $bar, @return{ @keys } ) = 1 .. 10;
[download]

And perhaps can you give an example that doesn't use $_ with all its aliasing behaviour just adding to the noise.

The aliasing behaviour isn't noise, it is exactly the point. The aliasing behaviour makes a difference because the assignment returns the list of lvalues that were assigned to. If the assignment returned copies, then nothing in the original array would change. Let's do that again, but making sure to pass copies this time:

#!/usr/bin/perl
use strict;
use warnings;

use Data::Dumper;

my %return;
my @value = qw( foo bar baz quux );

$_ = uc $_
    for @{ [ @return{ qw( a b c d ) } = @value ] };

print Dumper( \%return ), Dumper( \@value );

=begin output
$VAR1 = {
          'c' => 'baz',
          'a' => 'foo',
          'b' => 'bar',
          'd' => 'quux'
        };
$VAR1 = [
          'foo',
          'bar',
          'baz',
          'quux'
        ];
[download]

This time, the changes are lost in the mist of time, because we didn't operate on the list of lvalues assigned to, we operated on copies of their values.

Makeshifts last the longest.