First, I think I saw somewhere something like, "%perl6hash{$key}{$key}" and the lack of context prefixing made me feel very sad. I resist change, and I really like the way perl uses $ in scalar contexts and @ in array ones. If "%perl6hash{$key}{$key}" is a scalar, why the % prefix? Kinda reminds me of the changes to nwn2 — too much response to critics and not enough actual innovation. But I know almost nothing about it, so I'm probably totally wrong.

I did share the same exact feeling because the old current behaviour does make sense. But the more I think about it, the more I realize the new one does as well, and probably more too: in fact the former has some corner cases in which it doesn't square well. I can remember in particular a discussion with Uri Guttman in clpmisc... if $href contains a hashref, then what is $href->{'item1','item2'} to mean? To be unambiguous you have to use the other kind of dereferencing:

my $multi=${$href}{'item1','item2'};  # "multi"...
my @slice=@{$href}{'item1','item2'};
[download]

But to resolve the ambiguity with the first attempt the core developers made a choice that IMVHO is in retrospective not the most intuitive one. However in Perl 6 all possible ambiguities will be resolved with a consistent design and as a plus explicit referencing and dereferencing will be required on a much more sparse basis than currently is.

Said, this, I'm sure quite about everyone has some "favourite" piece of Perl 6 syntax or semantics that he doesn't particularly like. I, for one, I'm in the camp of those who dislike the choice of unicode operators at all. I suppose I could easily be called "old-minded". I guess I am. But given that they will have ASCII only equivalents and that both will be more or less equally easy to type and read, I don't care much after all.

Having done some tests, and it also seems to make perfect sense to me... the 2nd version, my @slice=@{$href}{'item1','item2'}; Is the only one which seems valid for the purpose at hand. The target is to get a hash slice, which is array (ahem, list) context, so @{$href} is what places it in that context, dereferencing as an array, to mimic @hash{'item1','item2'}

${$href} on the other hand attempts to dereference as a scalar, which, in my test, didn't yeild anything but undef:

#!/usr/local/bin/perl

use strict;

my %hash = map { chr(ord('@')+$_) => $_ } (1..26);
my $hashref = \%hash;

my @list = qw/A B L S Z/;

my @slice = @{$hashref}{@list}; 
my $multi = ${$hashref}{@list};

print '@slice == ['. join(', ', @slice). "]\n";
print "\$multi == '$multi'\n" if defined $multi;
print "\$multi == undef\n" if !defined $multi;
[download]

Output:

@slice == [1, 2, 12, 19, 26]
$multi == undef
[download]

So it seems only one of these gets the desired result, and thus no ambiguity.