I know the Reason guys want to tackle project setup / build / deps in addition to their syntax changes. I've found the current release's bsb toolchain to work pretty well for js targets but I haven't tried to set it up for native compilation.
I'm concerned about the ReasonML -> OCaml -> Bucklescript -> JS compilation chain. The laws of leaky abstraction pretty much guarantees this is not a robust way to do things.
I also wished the ReasonML folks started from scratch, instead of inheriting OCaml's baggage (no forward references, a plethora of file types to deal with, no UTF8 strings without bringing in an external lib, and so on).
You don't need to use bucklescript toolchain to write Ocaml, it has a very good package manager, the build-system tooling is getting better, already has great editor support for many years now(merlin).
I think the tooling scene is much better than Haskell. Not sure what you mean by "no forward references"?
I'm guessing they are talking about having implicit mutual recursion between items in a module, like Haskell has.
I probably got the name wrong, but it's the ability to use a function before it is defined.
In OCaml/ReasonML, you'd have to use the rec keyword and structure your codebase in a particular way to define mutually-recursive functions. It is a small but noticeable papercut, especially since recursion is so common in a functional language.
F# code (with a catch) --> F# AST --> Bable AST --> JS
The big thing here is that the F# code you write has slightly different semantics than "normal" F#. That's because the runtime environment is different, and so you can't escape that. Rather than attemp to gloss this over, the Fable creators are pretty explicit about this, including documenting each of the (small) differences. The result is pretty good. Abstractions don't seem too leaky from my vantage point.