This could be surprising, but the scenario already exists in production. In JavaScript's strict mode, Safari applies tail call optimization, but systems relying on V8 don't.

To illustrate, the following code causes a stack overflow for me in both Google Chrome and in Node.js, but runs without issue in Safari.

  "use strict";
  const countdown = (n) => n == 0 ? console.log('done') : countdown(n-1);
  countdown(100000);

If I try to trace through the risk profile of bringing TCO into software engineers’ toolkits, it seems that the fear would be of the software engineers growing recursion-happy and writing functions that overflow the stack by inadvertently not leveraging TCO, more than they write recursive functions today that overflow the stack given that V8 offers no possibility of TCO at all? It just doesn’t add up, V8 with TCO and no safety keyword would simply be better than V8 today with neither, so it would still be a strange basis for not delivering the feature.

I personally had the opposite experience on this one. I had always been told that V8 was a highly efficient JavaScript engine, so I didn’t really worry about writing recursive functions to which I had assumed such a fundamental optimization would be applied. After all, TCO will take a recursive call that would have O(n) space complexity, where n is the recursion depth, and evaluate it in just O(1) — it didn’t seem possible that a highly optimized JavaScript engine would miss something so fundamental. I was both surprised and disappointed when I found out I wouldn’t be able to safely use recursion in JavaScript code that would run on Google Chrome, Android, or Node.js, unless I could guarantee a relatively small depth.