Uh, I'm not sure what + would return for a Pair, but I'm pretty sure it's
not a pair.  A little P5ism sneaking in there?  :-)

: But here is a new idea: Since the parser knows that the bare block is
: followed by no trailing comma, how about we using it as a disambiguating
: device, and define that it never collapses?
:
:     map { $_ => $_ } @foo;  # closure
:     map { $_ => $_ }, @foo; # hash

A block can be arbitrarily long.  I worry about disambiguating it by
something could come lines later.  It's the /x problem all over again.
Plus, I think many folks would rather think of the closure comma as
optional rather than mandatorily missing.  Besides, if they can't
keep the {...} straight, they're not gonna keep the comma straight either.

: And maybe it can be extended over adverbial blocks, too:
:
:     @foo.map:{ $_ => $_ };  # closure
:
: Also as control structure body, just for consistency's sake:
:
:     for @foo { $^x => $^y };
:
: Is it a sane approach?  I have just tentatively implemented it as r2305
: if people would like to experiment with this proposal.

I really think for clarity it has to be disambiguated by either
something syntactic on the front or something semantic at the top level.
It's probably pretty easy to catch the error of saying

    map { $_ => $_ } @foo;

when you mean

    map { hash $_ => $_ } @foo;

or

    map { list $_ => $_ } @foo;

because map wants a closure as its first argument, not a hash.  I still
kinda like the rule that it's a hash if the top-level looks like some
kind of list of pairs.  It optimizes for the common case.  Closures
returning pairs are a rarity.

Perhaps one of the new Perl 6 features makes this unnecessary, but I
often found myself doing just that when I wanted an effective method
to test multiple times if an element is in an array, like this:

my %foo = map:{ ( $_ => 1 ) } @bar;
if( %foo{'abc'} ) ...
if( %foo{'def'} ) ...
if( %foo{'zrs'} ) ...

That closure is returning a pair for each array element.

There are lots of blocks that shouldn't take colons.

: >I really think for clarity it has to be disambiguated by either
: >something syntactic on the front or something semantic at the top level.
:
: I agree.  See my previous paragraph for an example.
:
: >I still
: >kinda like the rule that it's a hash if the top-level looks like some
: >kind of list of pairs.  It optimizes for the common case.
:
: I agree.
:
: >Closures
: >returning pairs are a rarity.
: >Larry
:
: This is beside the point but ...
:
: Perhaps one of the new Perl 6 features makes this unnecessary, but I
: often found myself doing just that when I wanted an effective method
: to test multiple times if an element is in an array, like this:
:
: my %foo = map:{ ( $_ => 1 ) } @bar;
: if( %foo{'abc'} ) ...
: if( %foo{'def'} ) ...
: if( %foo{'zrs'} ) ...
:
: That closure is returning a pair for each array element.

How 'bout:

    %foo{@bar} »=« 1;

That seems a lot clearer to me.  If you don't like hyper, how about

    %foo{@bar} = (1..2:by(0));

:-)

    %foo{@bar} = 1 xx @bar;

    map { $_ => $_; } @foo;

This works too:

    map { ;$_ => $_ } @foo;

But () is still only a grouper, so this won't do:

    map { ($_ => $_) } @foo;

Does this make sense?

I imagine

map { .foo } @objects;

to be interpreted as

map method { $?SELF.foo } @objects;

The distinguisher were the need of having a defined $?SELF in the
closure. My idea is the following:

         | number of |      as      |
class   | invocants |     multi    |
--------+-----------+--------------+
Sub     |     0     |  > 0         |
  $?SELF | undef     | := @?SELF[0] |
  @?SELF | undef     | invocants    |
--------+-----------+--------------+
Method  |     1     |  > 1         |
  $?SELF | invocant  | := @?SELF[0] |
  @?SELF | undef     | invocants    |
--------+-----------+--------------+

I used the @?SELF array mostly for illustrating my idea concerning
$?SELF, but it might be usefull for things like

multi sub foo
{
    # use @?SELF here