Unfortunately it's the name we're stuck with though, and it makes a lot more sense because ECMA releases are yearly.
Not judging, but if high profile articles and browser vendors started addressing it correctly we wouldnt have any issues migrating, more syllables or not.
I'm a touch confused...are you saying that if everyone used the year-based nomenclature, the inconsistent support would go away? Today in 2017 I have some ES6/ES2015 features I can use as well as some ES7/ES2016 features, but there are also other ES6/ES2015 that I can't count on being supported, and quite a few ES7/ES2016 features I can't count on.
How are these problems alleviated if we change the name we use? Or have I totally misunderstood your point?
Side Note: I'm not a fan of using a year for the same reason we (i.e. most everyone) stopped using it for versioning - That previous iterations have been done on a yearly cycle does not mean that future iterations will follow that schedule. That, however, is a side argument that neither of us touched on.
I'm pretty sure this ship has sailed for ES6. It's been referred as such while it was in development for so long, it's here to stay.
The next one might be different. But they really need to come up with a better than than "2017" or whatever. There's no similar problem with C or C++, and that's likely because they use 2 digit years, not 4 digit - C++17 isn't super short, but it's not a mouthful.
Not judging, but if high profile articles and browser vendors started addressing it correctly we wouldnt have any issues migrating, more syllables or not.