[coroutines]

I would really be interested to know why we need a special syntax for tail calls. (genuinely curious)

I'm from Lua originally and we've had tail calls forever... why would you point them out? It should be obvious:

return wat()

[LewisJEllis]

I'm not on TC39, but I sit next to and work closely with people who are, and my understanding (confirmed by this article) is that the primary concern is about stack traces of existing code, specifically code with function calls in tail position.

With implicit tail call elimination, those stack traces will change in non-trivial ways that could affect debugging processes or break existing tools.

I've also heard some concerns about implementation difficulties, but I know at least one major engine has implemented PTC as specified in ES2015 without issue. I think (and hope) these concerns are secondary to the discussion about stack traces and backwards compatibility.

tl;dr: as with almost every "why is it like that" question about JavaScript, the answer is "because backwards compatibility".

(I also started with Lua and have adjusted to JS over the years; they have more in common than many people realize!)

[yoklov]

I'm not particularly in the loop on this, though I have talked about it (idley) with a member of TC39, but my understanding is that implementation difficulties are a big part of it. SpiderMonkey and Edge both are having difficulties implementing it without hurting the performance of average code.

[kansface]

As the article pointed out, the ternary operator, lambdas, and &&/|| make it easy to miss a tail call. I tend to agree with you - the later will see reduced use with named arguments while optimizing for the former doesn't make much sense.