Using curly braces for blocking is a non-starter because they're used for a lot of other things, and honestly, bracket pairs like (), [], {} are way too precious, imo, to squander on something like blocks. Parens () are exclusively for function application; square brackets [] are exclusively for indexing operations; curly braces {} are for type parameterization. The other option that C++ popularized the use of is <> — but that's syntactically sketchy since both < and > are valid by themselves. It makes parsing a complete nightmare — both for machines and, to a lesser extent, people. I wouldn't be completely averse to indentation-based blocking, but I'm not really a huge fan of it either. I'm cool with the way both Matlab and Ruby do it, which is using `end`. Could conceivably change, but relatively trivial syntactic alterations like this are a really low priority. What we have now works well and is familiar to both Ruby and Matlab programmers.
Neither do many foreign language tokens like 我是加拿大人 but that doesn't stop me typing them in quickly using the IME. Admittedly those brackets aren't in any IME I know, but maybe they should be.
Matlab already allows you to omit the 'end' from function definitions, which many people find easier to read, and my experience seeing people transition from Matlab/Octave to Python+Numpy+Scipy is that people get on board with indentation-delimited blocks, because that's the way they write code anyway. But I agree - at the moment it's a pretty trivial thing. As a heavy user of Matlab, R and Py+N+S I'm looking forward to trying out Julia.
I personally found it worse to read, because it makes function blocks different from other blocks. Also, if you define nested functions in Matlab, all functions in the file have to be closed with end anyway.
Nothing is as bad, though, as the default Matlab behavior of not indenting first-level function code. This makes it really hard to scan a file with multiple functions and see where they separate.
I was referring specifically to supporting the Octave conventions, a superset of Matlab's, which make it easier to match up begins and ends.
When I said "easy fix" I meant "a trivial extension to the parser" without realizing you would translate that to "really low priority". Guess I'll save my non-trivial suggestions. :)
