Babel implements multiple variants of this proposal to help TC39 test and gather feedback from the community. As with all proposals, expect changes in the future.

However, this would lead to further divergence. Tooling that is built around the assumptions imposed by template literals wouldn't work. It would undermine the meaning of template literals. It would be necessary to define how JSX behaves within the rest of the ECMAScript grammar within the template literal anyway.

ECMAScript 6th Edition (ECMA-262) introduces template literals which are intended to be used for embedding DSL in ECMAScript.

JSX is an XML-like syntax extension to EcmaScript (https://facebook.github.io/jsx/).

It uses the new standardized format for code modules included in the ES6 revision of JavaScript, instead of previous idiosyncratic solutions such as CommonJS and AMD.

TC39 urges caution when using Stage 2-or below proposals, as it might result in inadvertent pressure from the community to keep the implementation as-is instead of improving it for fear of breaking existing code or ecosystem fragmentation (e.g. using a different symbol like # instead of @ for decorators).

The reasoning is that saying "ES7 Decorators" assumes that Decorators is expected to be in ES7. I mentioned this in my last post regarding compiling node_modules, but being in a particular Stage doesn't guarantee much: a proposal can stall, move backward, or get removed entirely.