I added a few notes on how to try Wasocaml. Don’t expect everything to work now as this was indeed a quick prototype (more on this below).
The goal of Wasocaml was to convince the Wasm-GC working group of the usefulness of i31ref because we knew it would be needed by OCaml. Without this work they may had been removed from the proposal. We presented the work in January to the working group. In March we also presented this work at the Dagstuhl seminar on the foundations of WebAssemby which was the opportunity to discuss with some active members of the Wasm community such as Andreas Rossberg, Ben Titzer and Conrad Watt. In April, the Guile compiler to Wasm-GC was also presented and it was also using i31ref. Having two languages using i31ref convinced the working group. This is what allows Wasm_of_ocaml to use i31ref today. 
Wasocaml is also the first compiler for a real-world functional languages to Wasm-GC. We developed many strategies for the memory representation of values. For now we only presented two of them (more are coming!) and they should work for other languages/compilers. Wasm_of_ocaml and Guile are using similar techniques to what we presented.
A little bit more about the differences between Wasocaml and Wasm_of_ocaml… First, Wasm_of_ocaml being a tool external to the compiler, it is of course easier to deploy quickly. Wasocaml starts from Flambda and will thus benefit all the optimizations that are missing from the bytecode. Binaryen will be able to recover some performances but it has its limits. Moreover, Wasocaml is going to play nicely with separate compilation. Also, Wasm_of_ocaml is limited in its value representation choice (it must represent blocks as eqref arrays) whereas Wasocaml can use more sophisticated representations.
Also note that none of the two are actually usable in a production today. They both depends on many Wasm extenstions (typed function references, GC, tail-call, exception handling, string reference…) that are not yet available in browsers (you can use them in chrome if you turn some experimental flags on).
Alongside all the future works that @lefessan described, I’m also formalizing the compilation of flambda to Wasm-GC with a proper semantics.
On a related note, we indeed implemented Owi, a Wasm interpreter written in OCaml. It was a way to experiment with language extensions. Currently, our main work on the interpreter is to add the possibility to do symbolic execution of Wasm code (aka whitebox fuzzing). This allows to automatically find input values that lead to a crash in the program. The nice thing is that it allows to find bugs in code written in another language and compiled to Wasm (e.g. C).