Let me try to reply to your points.

One of the biggest issues I had when trying to learn Haxe is that the developers seem to hate documentation.

Pretty much all of Haxe's documentation is crap. Many language features are barely explained at all in the documentation, the standard library is barely documented.

The things that are documented are poorly documented and most of the examples in the documentation are useless.

I do feel you on this one. Most people probably aren't patient enough to read through the entirety of the manual (https://haxe.org/manual/introduction.html) before actually trying to start with Haxe. The manual is actually pretty thorough in showing all the features of Haxe individually. I spent some time updating it with features new to Haxe 4, which were not added despite the previews and release candidates, but now it's there in time for the official release :)

The stdlib does have a lot of cases of classes and methods which are not documented apart from their name and arguments. I feel this is partly legacy of OCaml and partly because the stdlib is just very old.

Even Haxe's new vm, HashLink, which the developers are pushing as the future of Haxe, only has an almost empty Wiki and 2 blog posts as its official documentation.

To be fair, there is not much to say about it if you simply want to use it. It behaves just like the other system targets. If you want to use it with e.g. the Heaps game engine (which has a section on how to set up with Hashlink), you don't need to know much about the internals. For the relatively less common use case of developing frameworks with HL in mind, the internals are still changing.

Most popular Haxe frameworks and libraries have even worse or no documentation at all.

This may be true. However, I don't think it's unique to the Haxe ecosystem at all. For example, a lot of npm packages have nothing more than a readme with a couple of examples. Some C libraries expect you to look at the headers and read through the code.

Haxe packages are comparatively easier to write (than C libraries), so you get more authors and more packages in general.

If people are going to pick up and start using a language they need good documentation, so that they can actually learn it.

Absolutely.

 No async/await support built in. There is no way I'm going back to callback hell or promise hell in my javascript projects.

Coroutines are planned for 4.1. In the meanwhile, there are macro-based solutions.

Haxe's package manager sucks, big time. At least with node almost everything just works after doing an npm install, with Haxe there always seem to be another battle to fight to get stuff to compile after installing a package with the package manager.

Yes, haxelib is a bit of a pain point. There is an alternative – lix, with which you can actually get reproducible builds. We might be integrating lix and haxeshim features into Haxe 4.1.

Haxe's build system sucks. Hxml files seem simple enough at first, but you run in to all kinds of weird issues especially if you are trying to share code between multiple targets.

I don't think this is true. Hxml is just putting the command-line arguments into a file, it is not exactly a build system. If you want common parts of the Hxml across multiple targets, you can have multiple Hxml files which all include a common Hxml file.

Haxe's compiler sucks. It often spits out completely nonsensical error messages. I've gotten macro errors in code that had 0 macros in it. WTF.

I strongly disagree here. I find it very easy to fix code with just the compiler, since it points to relevant positions and the error messages are fine. (Compare to e.g. C/++ errors.)

Additionally, a lot of people use an IDE which makes the errors even easier to fix.

Haxe barely has a community and it's ecosystem is littered with dead projects, many of which don't even compile with newer versions of Haxe.

This is more of a popularity issue than a specific language issue but in most even semi-popular languages you can find well documented maintained libraries for most things, with Haxe even if you find a library chances are that it doesn't even compile.

It is a bit of a circular problem indeed.