I've used Haxe in several production projects, and if I'm starting a new code-base from scratch I would pick it again. (I prefer type system, the cross-compilation options, and the meta programming)
But if you're migrating an existing code base, TypeScript has a more obvious path forward. Because TypeScript is a superset of JS, it means that all of the JS files in your project will be compiled by TypeScript as is. And you can add the extra typing information as you go, it doesn't have to be an "all or nothing" transition.
Compare to Haxe, where you have to create a separate *.hx file, with a slightly different syntax. You can either translate all of your code (a massive undertaking), or type external files as an `extern Class`, or just use `Dynamic` (equivalent of TypeScript's "any"). But all of these involve a little bit of work for every single part of your code base, so it's going to add up.
From what you say most of those problems are just syntactical, isn't it? Somehow I started to believe that it is a matter of visibility and self selling skills in the haxe community.
The problems you mention seems to be possible to solve with software (AST generation and transformation) however it still has to be done. Let's hope we will see soon a project like that in haxe-land.
You are right that the difference is syntax, but the thing is, JS syntax will always be different from Haxe syntax. You'll never be able to use "jQuery.js" as valid Haxe code, but it is valid TypeScript code.
There might be some interesting possibilities. For example back2dos has an example of Haxe seamlessly integrating with external ".as" files on the Flash target. This could be conceivable for other strict languages like Java or C# too. You might even be able to seamlessly integrate with ".ts" files, because they have some typing information. (That would be a fun project!)
But JS dynamic typing can be pretty crazy, and I'm not sure how feasible it is to be able to infer type information from JS source code without special type hints. It would end up just calling everything "Dynamic", and then you're getting no benefit.
But if you're migrating an existing code base, TypeScript has a more obvious path forward. Because TypeScript is a superset of JS, it means that all of the JS files in your project will be compiled by TypeScript as is. And you can add the extra typing information as you go, it doesn't have to be an "all or nothing" transition.
Compare to Haxe, where you have to create a separate *.hx file, with a slightly different syntax. You can either translate all of your code (a massive undertaking), or type external files as an `extern Class`, or just use `Dynamic` (equivalent of TypeScript's "any"). But all of these involve a little bit of work for every single part of your code base, so it's going to add up.