After reading Peter's article on JavaScript I noticed
Brendan Eich stated that one the goals for Harmony is to be a better target for to-JavaScript compilers.
There are currently two popular compilers with some vague ES:Harmony compliance:
Although CoffeeScript has some compliance it's not designed to be an ES:Harmony compiler so it's not useful to this end.
Tracuer seems to be sticking more rigorously to the ES:Harmony specification but I don't know whether it intends to become a full ES:Harmony compiler.
Since the aim is to to compile ES6 down to ES3 it would also need to support ES5 features (and probably a switch whether to compile ES5 to ES3 or ES6 to ES3).
I've left a question on the Traceur mailing list.
The aim of such a compiler would be backwards compatibility with ES3. Not full emulation of ES5 and ES6 in ES3.
(shameless but relevant plug below)
Caja is reworking its ES5 support via ES5/3 and will do the same for ES harmony. So our structure would be implemented as a Harmony to ES3 layer which can be skipped for real harmony implementations, and then a separable loader that preserves the security properties that concern caja.
Like Traceur, members of the Caja team are part of TC39 (the committee defining ES Harmony).
I don't know about Coffeescript's plans, but it was mentioned during discussions of Harmony modules. Module loaders will likely have the ability to intercept loaded source code (via eval hooks) and rewrite it before module initialization, so if a module is written in CoffeeScript, a runtime CoffeeScript rewriter could be invoked at initialization time. This would allow apps to be composed of modules written in multiple languages that compile down to Harmony at load time.
One thing to note is that not everything in Harmony can be implemented easily via translation. For example, implementing weak maps correctly would require implementing your own garbage collector in JavaScript and even if you did that you would probably just reintroduce the host object/native object cycle problem.