I'm uninterested in any specifics, actually; I'm more interested in how much of the syntax landscape is cut off for future extension, particularly at the expression level.
It's one thing to insert semicolons in this case:
<ident> <op> <ident> <op> <ident>
<keyword>
and another to do so in this kind of case:
<ident> <op> <ident>
<op> <ident>
The former is unlikely to be problematic for future extension, but the latter more so. The general pattern in Algol-derived languages is for all statements (except for expressions, including assignments and procedure calls) to begin with a keyword. This substantially reduces ambiguity - semicolons are mostly redundant in this situation - and it seems to me to be a fine place in JS to automatically insert them.
Another distinctive feature of Algol-derived languages is that two adjacent expressions are generally not meaningful; for example, <ident> <ident> is not usually a valid expression sequence in Pascal, C, etc. (and in the presence of typedefs, it is actually a concrete problem when trying to parse C declarations, often requiring communication between lexer and parser to turn typedef identifiers into keywords for the purpose of parsing[1]). This in turn creates freedom for creating new keywords unambiguously, by including whitespace in the "keyword" (actually two words). But JS foregoes some of this, because <ident> \n <ident> will have a semicolon inserted on the line break. It's not too bad though, because new two-word "keywords" are not usually broken over two lines; but long expressions almost always extend over multiple lines at some point.
The 'latest revision of the future specification' you link to is, I think, the set of things the TC39 group has considered and agreed on. The list of things they are currently considering is in the strawman namespace[1] on that wiki. In particular, the "strawman:concurrency" page[2] currently says:
The infix “!” operator: An eventual analog of “.“, for making eventual requests look more like immediate requests.
