Suggestion: [no ASI if lookahead ...] constraint instead of SS rules for OptionalChain

[rbuckton]

What would the editor's opinions be on the introduction of something like a [no ASI if lookahead ...] constraint that could replace static semantics rules like https://tc39.es/ecma262/#sec-left-hand-side-expressions-static-semantics-early-errors in favor of something encoded in the grammar, i.e.:

LeftHandSideExpression[Yield, Await] :
  NewExpression[?Yield, ?Await]
  CallExpression[?Yield, ?Await]
  OptionalExpression[?Yield, ?Await] [no ASI if lookahead = TemplateLiteral]

A [no ASI ...] constraint would only kick in during automatic semicolon insertion, and would modify the rules in 12.10.1 to read something like the following:

1. When, as the source text is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar, then a semicolon is automatically inserted before the offending token if:
   1. One or more of the following conditions is true:
      • The offending token is separated from the previous token by at least one LineTerminator.
      • The offending token is }.
      • The previous token is ) and the inserted semicolon would then be parsed as the terminating semicolon of a do-while statement [14.7.2].
   2. And the offending token would not be the first token for a terminal or nonterminal immediately following one of these annotations:
      • “[no ASI if lookahead = tok]”, when the offending token is the token tok.
      • “[no ASI if lookahead ≠ tok]”, when the offending token is not the token tok.
      • “[no ASI if lookahead ∈ set]”, where set is a finite non-empty set of tokens, when the offending token is an element of set.
      • “[no ASI if lookahead ∉ set]”, where set is a finite non-empty set of tokens, when the offending token is not an element of set.
2. When, as the source text is parsed from left to right, the end of the input stream of tokens is encountered and the parser is unable to parse the input token stream as a single instance of the goal nonterminal, then a semicolon is automatically inserted at the end of the input stream.
3. When, as the source text is parsed from left to right, a token is encountered that is allowed by some production of the grammar, but the production is a restricted production and the token would be the first token for a terminal or nonterminal immediately following the annotation “[no LineTerminator here]” within the restricted production (and therefore such a token is called a restricted token), and the restricted token is separated from the previous token by at least one LineTerminator, then a semicolon is automatically inserted before the restricted token.

This would eliminate need to introduce illegal syntax in the grammar purely to rule it out later via static semantics rules. At present, only OptionalChain suffers from this, but such a change might benefit us as we continue to evolve the language with proposals like Throw Expressions.