Pretty much. ES6+ scores are from running compat-table's test suite (https://compat-table.github.io/compat-table/es6/), along with their weighting. If you click on an engine's name to go to a page about it, there's a report at the bottom with failing tests.
I never understood this complaint. You won’t get a “loop trace” when you convert your tail calls into an iterative algorithm. And your code will be less readable to boot.
V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also, imagine you have missing info from the error stack trace in production code running on NodeJS. that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.
Most Bun users don't even know about this (unless they are bitten by this). That doesn't mean absolutely no one cares or would not care even though such complaints might be uncommon.
Supposedly, although the team at Apple were able to implement it. I think they had some oddly named technology like Chicken which created a shadow stack trace? Half remembered.
Yes, It's called ShadowChicken, and it has negative implications for debuggability. To make debugging tolerable, JavaScriptCore added an (intentionally silly) mechanism called ShadowChicken: a shadow stack used by Web Inspector that can show a finite number of tail-deleted frames (they mention 128). It's has some tradeoff.
V8 team decided that it's not worth it, since proper stack traces (such as Error.stack) are essential for some libraries, such as Sentry (!). Removing some stack trace info can break some code. Also imagine you have missing info from the error stack trace in production code running on NodeJS, that's not good. If you need TCO, you can compile that code in WASM. V8 does TCO in WASM.
