Thank-you. ;-)

The point is not to actually insist on optimisation at present (though part of our motivation in cleaning up the Perl syntax is to make more optimizations possible). The point is to avoid making changes now that make later optimisations impossible. Which is what unifying arrays and hashes would do.

I am certain I haven't had any problems keeping my Ruby hashes and arrays separate (4)

I'm sure. But we don't just design for programmers as clueful and competent as you. We have to consider the common mistakes made by the vast majority of Perl programmers -- whose level of experience and ability is quite low. And then consider how the changes we propose will affect them.

In my (considerable) experience with such programmers, one of their most frequent difficulties is distinguishing between container types. I've published research¹ that indicates that removing syntactic cues to the differences between data types (as the Turing language did, for example) makes that problem far worse.

As to 5, I think I'll wait for Ex5, since I've not yet internalized A5, but I don't see how the brackets/brace is a problem if you are assigning a series of key/values to a hash

It isn't. In that particular case.

But that's not what I was talking about. I was talking about the case where a regex returns a "match object" (either directly, or via $0):

    $match = m/complex pattern/;   # match object in $match
    m/complex pattern>;            # match object in $0
[download]

Now array accesses on (say) $match give you the numbered captures:

    print "$match[1] was val for $match[0]\n";
    
    my ($key,$val) = (0,1);

    print "$match[$val] was val for $match[$key]\n";
[download]

Whereas hash accesses on it give you the named captures:

    print "$match{val} was val for $match{key}\n";

    my ($key,$val) = ("key", "val");

    print "$match{$val} was val for $match{$key}\n";
[download]

But if there's no syntactic distinction between arrays and hashes (represented here by a hypothetical, unified $match<...> accessor), how do you distinguish between hash-like and array-like look-ups on non-literal keys:

    print "$match<0> was val for $match<1>\n";          # array look-u
+p
    print "$match<'val'> was val for $match<'key'>\n";  # hash look-up
    print "$match<$val> was val for $match<$key>\n";    # ???
[download]

Deciding that last case on the basis of run-time type of the values in $val and $key is both much slower, and vastly more error prone (in light of Perl's free-and-easy interconversion of numbers and strings).

So people will be generally forced to make the distinction explicit anyway:

    print "$match<$val> was val for $match<$key>\n";    # ???
    print "$match<+$val> was val for $match<+$key>\n";  # array look-u
+p
    print "$match<_$val> was val for $match<_$key>\n";  # hash look-up
[download]

Which is far worse than what we have now.

1. They didn't select me to help Larry design Perl 6 just because I'm even weirder than he is, you know! Well, not solely on that basis, at least. ;-)