> I find it's useful when my typescript source matches the generated Javascript code as much as possible.

Is this that worth? In the past I was able to read past async/await desugaring generated by TypeScript, and there are several useful non-JS syntaxes that are much easier to read than that (e.g. enums). Of course it would be great if ECMAScript eventually adopts them, but that doesn't seem like a strict requirement for me.

Async/await was implemented according to the ECMAScript spec - for a while it existed in typescript but not yet in browser runtimes, but it was fully specced out as a javascript feature rather than a typescript one. And when configured to emit ESNext JS files, typescript would emit the async/await calls verbatim, rather than transpiling them. After all, at that time async/await was valid, spec-compliant javascript (that hadn't yet been implemented in all browsers).

This is true for a number of features, most recently explicit resource management, that required syntax that was part of ECMAScript, supported in typescript, but not yet implemented in mainstream runtimes. In these cases, typescript is doing the same thing as Babel and converting new JS to old.

The syntaxes under discussion are ones that were implemented in typescript without an ECMAScript proposal, and typically are completely non-standard, and may well never be implemented in browsers, or if they are, be implemented completely differently. For example, the original decorators implementation was completely different to the one now being proposed, and enums could well end up going in the same direction.

This confusion about what is typescript, and what is javascript is exactly why I think avoiding the typescript-only features is a good idea. I've seen a lot of people make this mistake (and it's a very reasonable mistake to make!) and I think it's easier to explain what typescript is actually doing if you make it clear that it's only doing type-level stuff.