Implementing support is not the same thing as turning a feature on by default.
The TC39 process states that limited spec changes may still occur after a stage 3 proposal. Until a proposal reaches stage 4, it should be hidden behind a settings flag. This helps us prevent situations like flexbox, where users code against a specification and find out later that their code has broken in subtle ways.
> as well as implementations into trans pourers (eg Babel)
Which is meaningless. Babel is not a part of the standards process, they're free to ship anything they want. Encouraged, in fact, because that provides more in-the-wild usage data.
It is super meaningful - it helps identify potential issues in real world use-cases and it creates effectively a "market" of people already using the feature who want to be able to use it without transpiling. It's also pretty rare that the implementation changes meaningfully after implementation into Babel from around stage 2.
I should have used a more descriptive term than meaningless.
Transpiler implementations do not count as hard restrictions on whether or not a proposal can change in the future. They're allowed to do whatever they want -- the fact that they create demand is very useful, but should not be seen as a restriction on whether or not the standard can evolve past that point.
"It's also pretty rare" is exactly the problem. They can change. When browsers ship a non-standardized behavior that's on by default, they are effectively cementing it. It is very hard to correct a broken implementation that is live, in the wild, on normal sites. The fact that these changes are rare doesn't make it less important to follow the established process. Stage 3 is one last safety check before the feature gets turned on for everyone.
What is the point of having a stage 3, if browser makers treat it as equivalent to stage 4?
The TC39 process states that limited spec changes may still occur after a stage 3 proposal. Until a proposal reaches stage 4, it should be hidden behind a settings flag. This helps us prevent situations like flexbox, where users code against a specification and find out later that their code has broken in subtle ways.
> as well as implementations into trans pourers (eg Babel)
Which is meaningless. Babel is not a part of the standards process, they're free to ship anything they want. Encouraged, in fact, because that provides more in-the-wild usage data.