I had a look at the Perl source code, this is what I *think* is happenning:

When Perl detects a simple array/list assignment, it does a Perl_force_list on the left operand of the assignment, @b, including an implicit clear of the left operand, and hence introduced the side effect to the right hand side of the assignment, @a. Somehow the optimization engine decides that a temporary copy of the right handside is not required because it is a simple assignment.

Thus this assignment

@b = @a;
[download]

is the equivalent of:

@b = (); # temporary internal step
@b = @a;
[download]

And because the code defined *a = *b earlier, the assignment @b = () affected @a on the right hand side before the assignment, and hence the assignment @b = @a is really doing @b = () and @b = () again. Therefore the value of @a and @b after the assignment are both undef. But why does the resulting list contain two undef's? Ummm... this reminds me of another post by BrowserUk a few days ago on the side effect of print join '|', @a = %b... Another weired behaviour of Perl

I modified the list assignment slightly -

use Data::Dumper;

*a = *b;
@b = (1,2);

@b = @b; # perl detects this is assigning into same variable
print Dumper(\@b);

@b = @a ? @a : (); # new assignment

print Dumper(\@a);
print Dumper(\@b);
[download]

And I am getting the correct output:

$VAR1 = [
          1,
          2
        ];
$VAR1 = [
          1,
          2
        ];
$VAR1 = [
          1,
          2
        ];
[download]

From which an obersation is made: the right hand-side @a ? @a : () is evaluated first into a temporary copy of @a, before assigning into @b, thus preserving the original values of @a.

My personal opinion is that we should be aware of the side effect. Report it as a bug or not, it's certainly an interesting recepie for another JAPH. :-)