"The semicolon is necessary for disambiguation in a case like this..."

This is why semicolons should be mandatory or illegal. The whole "optional semicolon" thing is a mis-feature designed by language committees that can't make a decision. One's codebase becomes a mismash of lines with and lines without semicolons, sprinkled in as magic to make the compiler happy.

There are plenty of interesting language features which are useful -- support for "optional semicolons" isn't one of them. The feature needs to die, and people should just choose to use a language that suits their need to type -- or not type -- a ';'.

We should also use a fully-parenthesized prefix syntax so we don't get a mishmash of lines with and without parentheses used to override operator precedence!

I agree Javascript's "automatic semicolon insertion" is a terrible feature, but largely because the description is so hard to understand that programmers don't know when the semicolon is required.

In an expression-oriented language, like Xtend seems to be, the rule for when you need a semicolon is simple. The parser makes the longest legal expression it can, if that's not what you mean, then add a semicolon. It's no harder to understand than the lexer equivalent (the lexer makes the longest token you can, if you want to resolve the ambiguity insert a space), or the operator precedence rule (the parser will interpret infix operations using this precedence table, if that isn't what you mean use parentheses).

Matlab, for example, doesn't require commas to separate list elements, and doesn't require but allows semicolons at the end of lines, and nobody complains.

Sorry for not understanding, but can you explain what the ambiguity is here?

A C-like parser will keep parsing an expression as long as it's legal. Take:

    foo("bar") * a

It will parse the call to 'foo', then see the '*' which is an infix operator and parse the whole thing as a multiplication expression. In most C-like languages, '(' is both a prefix operator (for grouping) and an infix operator (for function calls). So:

    foo("bar") (a + b)

Is ambiguous if you don't require semicolons to separate expressions. The parser will parse the call to foo, then see the '(' and parse that as a call to the value returned by 'foo'. To stop that, you use the semicolon to stop parsing one expression, so the next '(' is treated as a prefix operator.

Wow, yes of course. For some reason I thought Xtend was whitespace sensitive, so just having a newline was enough.