It is 3 years since the last reply, I want to support the claim that hxcs is giving commerical value to Haxe by sharing my positive experiance with hxcs.
I’ve been using haxe for a commercial WPF Job, The primary language was C#, I wrote my assignments in haxe->cs and then merged the c# code with the greater project, the other team had no issue with using and analyzing my logic along with the CS code and came back with really helpfull feedback (which I fixed and applied to the haxe code).
The EIAE of Haxe, which is not avalible in CS at this time, prevented many bugs.
Of course I had to enable fast-cast etc, to make the code prettier, but the approch gave me better type infersion, syntactic sugar, remoting, and not to forget, many of the classes and business logic where reused later for other JS projects.
I later easily ported the Sqlite class to other Ado.net drivers, since the underlying API is anyway the same, which gave me access to record-macros (Which is more leightweight then EF).
With .net 8.0 I made use of the CLI for automatic compilation, in dotnet core, it will implicitly load all cs files within the src folder, in addition to the explictily included files and globs, also unlike java in cs the filestructure is not strictly tied to the namespaces so it is very easy and streight forward to mix haxe and cs projects, and incrementally switch classes from csharp to Haxe or Haxe to CS if neccessary.
So to summerize, the haxe cs target gives great value to Haxe by enabling the use of dotnet frameworks, and the cs output enables projects to incrementally switch to haxe, while not requiring the whole team to learn Haxe.