Generally, the rule seems to be "insert a semicolon wherever the syntax messes up but can be fixed by adding semicolons". Then there are some special cases (++/--/continue/break/return/throw/arrow functions/yield) with more specific rules about where semicolons are placed and when; those are probably why the example produces "unexpected" results.

I think the added complexity of these special rules and cases are an unnecessary burden, and honestly the language should never have allowed leaving out semicolons when it was clearly designed to have semicolons.

Seriously, semicolons are something that was baked into the design assumptions of JavaScript. Python's an example of a language where the syntax was clearly designed from the inception to avoid them. Most such languages make explicit tradeoffs and TBH I'd much rather have semicolons than whitespace sensitivity.

Periods are not needed if each sentence span exactly one line, which is the case in programming languages. the separators &&, ||, () do the intra statement disambiguation while for interstatement {} suffice. ; bring no value in practice. Using multiples semi colons on a single line is pathological code that should never exist in the first place.

When I code in Kotlin (which is not whitespace sensitive like python) I really realize that reading semicolon less code is smoother, it takes less cognitive resources (parsing is faster) and is more pleasant because the reading is not interrupted by vacuous symbols. There are no ambiguities in practice. The thing is, habits take time to die but ask anyone that has experience in an officially semi-colon less programming language, most will tell you it is a net improvement. BTW the vast majority of newer programming languages are semi-colon-less (Kotlin, Go, Swift, Julia, Scala, etc)

A series of individual invocations of arcane commands; sometimes with pipes

Though it is not uncommon for one-liners to exist (sometimes with sub-shells). In that case the semicolons are not optional. Even in cases where another type of escape is used to visually break up the one liner into a list like series of commands which happen to be run concurrently; most frequently for really long pipe-sets.

   return (
      [item]
   )

   return [
       item
   ]
    

    let c = a + b
    (() => { ... })()

    let c = a + (b(() => {...}))()

    let c = a + b
    ;(() => {...})()

Whereas JavaScript technically requires it but many browsers decided to support parsing missing semicolons for the sake of making bad websites render (much like how most browsers will support a variety of incorrectly formatted HTML documents as well). The problem here is that JavaScript's syntax wasn't designed to have semicolons omitted. Which leads to all sorts of edge case problems and no clear answer on how they should be handled.

> Most ECMAScript statements and declarations must be terminated with a semicolon. Such semicolons may always appear explicitly in the source text. For convenience, however, such semicolons may be omitted from the source text in certain situations. These situations are described by saying that semicolons are automatically inserted into the source code token stream in those situations.

Which, to me at least, reads as saying JavaScript must include a semicolon but interpreters must be tolerant of the occasional missing semicolon where intent is obvious.

Somewhere along the line the attitude seems to have changed from "you should include them" to "don't bother". Or at least that's perception I get these days.

I've not been heavily involved in JavaScript for a few years but I was one of the early adopters back in the days of Netscape Navigator and, later, Internet Explorer (albeit with it's differing but ever-so-similar "JSScript").

As an aside, since I'm talking about the early days of web scripting, wouldn't it be great if we brought back the language property of <script> to support other languages. Wouldn't be sensible in practice (for a whole plethora of reasons) but one can dream....

JS appeared in Dec 95 and the first ECMA spec came in June 97, so that's a pretty narrow window. But it's certainly true that ASI style (omitting semicolons) was relatively rare before, say, 2010-2014 or so. Its subsequent rise in popularity is probably thanks to Node (which uses ASI style), and a small group of ASI developers whose code suddenly got more visible once npm came along.

But as a practical matter, the rules on ASI have been the same since forever, and the rules are that they're nearly always optional. The only realistic case where omitting them causes issues is when you start a line of code with a parenthesis or a square bracket. Back when ASI first got popular that was the one big gotcha, but nowadays thanks to linters even that's not an issue.

What you may be remembering is, some years back there were some cases where certain JS tools didn't support ASI. Famously, there was a thing where a popular minimizer (JSMin) broke ASI code and Crockford didn't want to fix it because he didn't like ASI style (he later relented). But I've never heard of an actual JS engine not supporting ASI correctly.

In theory yes, in practice not really. IE4 was the first version of JScript to be based on ECMA and that was released at the end of 1997. But in that era people didn't update regularly. Sure some folk (myself included) installed IE4 on top of Windows 95 SE[1]. But a lot of people wouldn't have had access to IE4 until they bought a new PC with Windows 98 pre-installed. So there was a good few years in practice.

Also worth noting that the web changed so much between 95 and 98. It might have only been three years in real terms but it felt like a lifetime in terms of technical revolutions.

[1] If I recall correctly, I had IE4 because it came on a .Net Magazine cover CD (not to be confused with Microsoft .NET: https://en.wikipedia.org/wiki/Net_(magazine) )