That would just be a default in my fork. Since the output will be massively configurable, you can use any style you can imagine, including a single line with all the braces and semicolons and whitespace you want. See http://oai.cwi.nl/oai/asset/10876/10876D.pdf for a resource on defining grammars for AST to CST transformations.
Yes yes, but some do, it was a giant flame war, and I'll admit that it can be a practical issue (if not a correctness one) for javascript to rely on automatic semicolon insertion if it means you can't use your minifier of choice.
But trying to use a "validator" that validates a languages other than the one you are writing is just plain insane.
I'm not sure I agree that ASI is an "error-correction feature". Die-hard always-semicolon advocates certainly would like to paint it that way, but I think that may be rewriting history a bit.
The ECMAscript standard[1] and the creator of the language[2] are pretty clear about it. From what I know of parsing, anything phrased in terms of adding tokens post-lexing in order to make an invalid parse tree valid as opposed to encoding the semantics in the grammar itself is most definitely an error correction method.
I think that a lot of the confusion comes from taking the term "error" personally. Nobody wants to be told that their programming style relies on "error correction" to be parsed, but it's just an implementation detail of the parser, not some kind of qualitative statement about your programming skills. Changing the name does not change how the parser works, and does not make anyone involved a better or worse programmer.
Fair enough, but a statement like "compiled output shouldn't be relying on an error-correction feature" is only (self-evidently) true if we're using the informal, taking-it-personally connotations of "error correction".
Is he nuts? The compiled output shouldn't be relying on an error-correction feature. Especially since it might break minifiers and validators.