was introduced specifically to make the semicolon rule work for Typescript

It was introduced to add support for syntax locations that TS introduces that do not exist in standard TS. That is all our extension rule is for.

And also it was my understanding that the primary reason for a semicolon rule is not formatting but preventing programming pitfalls.

The intent of the rule is to be explicit with your semicolons so that you do not rely on ASI at runtime which has a few footguns.

It's both a stylistic concern because semicolons are optional and a correctness concern because ASI has some edge cases (eg the case you presented with a line leading with a ( and return statement with its expression on the next line).

Explicit semis are good style because it allows the dev to explicitly encode intent into the code to prevent ambiguity.

So I assume there are some Typescript-specific features that ESLint doesn’t know anything about and so no-unexpected-multiline wouldn’t know either.

TS does not add any features that impact this rule. Most new TS syntax that matters is either declarations or expressions and the rule only really cares about the latter and handles them.

JoshuaKGoldberg Says semi is mainly about formatting concerns, bradzacher says it’s about both stylistic and correctness concerns.

To clarify - I meant that it is a stylistic / formatting concern primarily, same as Josh.

I was just also pointing out why the docs talk about correctness and possible errors - because of ASI and the rare footguns with accidental multi-line statements.

The second definition mentions semicolons but in the same sentence says it’s about rules that don’t impact runtime behavior. In fact, the runtime impact is presented as the distinguishing feature compared to stylistic rules.

The presence of semicolons does not impact runtime behaviour - as long as you correctly write code.

You cannot compare

foo;
(bar);

And

foo
(bar)

Because they are two different code fragments. Instead the comparison would be with

foo
;(bar)

Which is the "no semi" approach to avoiding the footgun.

It's a stylistic choice - if you choose the no-semi style you have to write the no-semi style code and you must know and understand ASI to avoid runtime breakages.

Its the same with using if/for/while blocks or not (eg if (cond) {code} vs if (cond) code) - it's a stylistic choice and if you go for the no-block style you have to be aware of its limitations and the potential footguns.