Now that feature list for ES2016 aka ES7 is out, and doesn’t actually include any of the features most people talk about, it’s officially time to just stop using ES7 to mean “any proposed feature that may or may not even make it”.
Let’s get some terms out of the way in a tl;dr fashion:
TC39 = the people who write the spec.
How we got here
The first of such updates went through numerous name changes. ES.next, Harmony, ES6, then finally landed on Es2015. This was mostly due to the time it took for ES2015 to actually be finalized — 4+ years. Along the way, the goals and scope evolved, eventually realizing that instead having an arbitrary amount of time to make a new version, they should instead release a new version for each year.
Instead of ES6, ES7, ES8, etc. they would release a new version every year: ES2015, ES2016, ES2017, etc.. The theory being this would reduce pressure on TC39 since there’s always next year while also making it easier for browsers to implement these changes since they’d come on a more predictable schedule and most importantly be smaller in scope, excluding ES2015 which is rather large.
What do we call them, then?
The natural question you may ask is what do you call these features that have been proposed but not yet made it into any finalized spec? Personally, I think they should be called what they are, “proposed features” to layman but sometimes it’s helpful to distinguish where they are in the draft process.
With the new spec release cycle came a “stage” process for individual features. All changes and features go through stages 0–4, the most notable being that stage-0 features basically mean “not immediately rejected outright” (aka strawman) and stage-4 meaning the feature is final and ready for inclusion in that years spec cut. Which means it’s important to note that at any point in the stage the feature could be completely dropped. It doesn’t matter how much the community is relying on it via transpilers or polyfills, and a feature being dropped amongst controversy isn’t without precedence.
Although there will still be some transitional time, referring to a feature by stage is helpful to distinguish features which might be neat to dream about but unwise to rely on. It’s often extremely helpful as well since someone coming across your article, talk, tutorial, etc. at a later date can see which version of that feature you’re referring to. An article explaining how feature X works at stage-0 might be crucially wrong about how it works by the time it reaches stage-4.
As an example, you could say “stage-1 decorators”, which is an important clarification since the decorators spec changed rather notably after stage-0!