Yukihiro Matsumoto wrote about new lambda syntaxes:

> |f = ->(a) { ... }
> 
> [...]
> 
> |f = { : a,b=1|2 : ... }
> |f = { : * : ... } # equivalent to f = lambda { ... }
> 
> Unfortunately :+space causes conflicts as well.

I'm probably not in the position to criticize, but I still feel like I 
have to or I will regret not having done it later.

Is it really in accordance to Ruby's design mentality to introduce new 
syntax just because parsing the most obvious one is too complex?

This is how I understand the issue. A new syntax is being considered 
because this will be hard to get working:

l = lambda { |x, y, z = (x | y)| ... }

And because block arguments don't look much (and aren't handled much 
like) method arguments.

If this is not only for the above two reasons, but also because you 
think that the above sample is hard to parse visually then please 
consider other choices that are more obvious than arrows pointing into 
random directions:

f = def(x, y, z = x | y) { ... } # also need to allow def x() { ... }
f = fun(x, y, z = x | y) { ... } # a new keyword

Personally, I think this complete situation is not as much as a problem 
as it might appear. -- Blocks are a special syntax in Ruby and we have 
all gotten used to it. It is okay for them to also have a special 
argument syntax. Having default arguments with the current one is not 
hard. We don't need both method call semantics and special block 
semantics both at the same time. We could get rid of Proc.new without 
losing anything but the danger of confusion.

Sure, the C#, Perl and ECMAScript way of doing this has advantages like 
being able to assign closures to variables with the same syntax as with 
method calls. It also allows multiple closures per method and storing 
them in hashes without a second syntax. Should we switch to it? Should 
this have been the way for Ruby to do it since the beginning?

As stated above I think switching might be more trouble than its worth. 
Sure, if you learn Ruby you will at one point try to do "x = { exit }", 
but after a small surprise you will have learnt to insert the "lambda".

Now to the more difficult part. Would it have been better if Ruby would 
have merged blocks and lambdas since the beginning? This is hard to 
answer. When I was learning Ruby I thought that it would be great to be 
able to supply multiple blocks to one method without needing a different 
syntax. Has this been a limitation? Nope, but that could be related to 
users of languages automatically working around issues before they 
encounter them.

So would there have been a downside to Ruby having unified blocks and 
lambdas since the beginning? Yes, I think that

10.upto(20, { |i| puts i })

is harder to type and read than

10.upto(20) { |i| puts i }

One can now argue that it does not matter for cases where there only is 
a block:

1.times { } is the same as 1.times({ }) anyway.

Or that we could allow trailing arguments that happen to be blocks to 
appear outside of the argument list:

Array.new(5) { |i| i * 2 } == Array.new(5, { |i| i * 2 })

# It is hard to come up with methods that take multiple blocks which
# isn't very surprising.
ary.context_each(
   first: { |i| puts "First: #{i}" },
   last: { |i| puts "Last: #{i}" },
) { |i| puts i }

# Or:
ary.context_each(
   first: { |i| puts "First: #{i}" },
   last: { |i| puts "Last: #{i}" },
   middle: { |i| puts i }
)

I also think that you might be able to fix the arrow syntax by moving 
it. I think something like this is acceptable:

adder = (a, b) -> { a + b }

And perhaps:

printer = a -> { puts a }

And even more perhaps:

printer = a -> puts a

This is again very hard to parse. Perhaps even for humans. So:

adder = \(a, b) -> { a + b }
printer = \a -> { puts a }

Don't get me wrong here. It might be rare, but in this case I am not 
actually trying to talk you into changing the language. I think the best 
and least risky option is to just keep the current situation. I am 
usually for sacrificing backwards compatibility to gain more 
intuitiveness and simplicity, but in this case the problem is not big 
enough to solve it (yet?).