Okay. The example was bad. The intent was to show that if the value of something that is used on the right-hand side of the assignment, that can affect the semantic outcome of the statement, can be changed by the left-hand side of the assignment; then pre-evaluating that value would be an unsafe optimisation:

(crudely) adapting your example:

my @h;
my @i= (0..1);
@h[@i]= split //, $i[ 2 ]= "03";
print "(@h)\n";
__END__
Use of uninitialized value in join or string at P:\test\junk.pl line 4
+.
Use of uninitialized value in join or string at P:\test\junk.pl line 4
+.
(0 3  )
[download]

This shows that the value of @i used on the left-hand side is not evaluated until after the right-hand side has been completed.

I contend that this is the same logic as happens currently with

my %h; @h{ map{ int rand 100 } 1..4 } = 'A'..'D';
print 'Before:', %h, $/;
@h{ 1 .. keys %h } = delete @h{ keys %h };
print 'After: ', %h, $/;
__END__
Before:25A39D0C23B
After:
[download]

The reason no output is produce after the assignment is because the value of scalar keys %h used on the left-hand side is not determined until after the right-hand side has be completed.

Hence, the delete has taken place, it's value 0, the range generates an empty list and %h is empty.

I (mis?)read your "it's a bug" post to mean that you felt that the extent of the range should be determined before the delete took place, so that the result of the statemant was as if

my %h; @h{ map{ int rand 100 } 1..4 } = 'A'..'D';
print 'Before:', %h, $/;
my $keys = keys %h;
@h{ 1 .. $keys } = delete @h{ keys %h };
print 'After: ', %h, $/;
__END__
Before:6D59B60A75C
After: 4C1D3A2B
[download]

However, looking back I see that I had missed the (somewhat detached) smiley, and misinterpreted your irony. So...no harm done.