So this is "oxidized" because it tries to achieve the same features as Rust (e.g. "fearless concurrency" is mentioned, and avoiding GC)... Not because it actually uses Rust in any way right? Slightly confusing.
Yes, they've used this terminology for a while, even the recent technical paper on this effort was titled "Oxidizing OCaml with Modal Memory Management", though the word "oxidize" itself is never actually referenced or defined in the paper. A bit strange, I agree, though it's kind of catchy I admit.
Rust will probably become usable with custom tracing GCs (which is helpful if you're dealing with general graph-like data but still want the highest performance as far as practical) way before this effort reaches genuine feature parity with Rust. Not seeing much of a point in this, unless they perhaps intend to focus on the lowest-hanging fruit and have big O(x)Caml codebases that they care about.
OxCaml takes a different approach to encoding locality to Rust. Rust (arguably) overburdens the type-system with this information whilst in OxCaml this is orthogonal to the return types. In that sense it's a bit like algebraic effects. Personally I'm quite bullish on OCaml these days.
OCaml is a good language and these extensions are very welcome to existing OCaml programmers and programs, as well as many of the other extensions Jane Street has added. I don't understand what you mean here.
Your comment remains completely stupid regardless of how much of it is in the quote. OxCaml's goal is to be upstreamed. "I don't see the point in this unless people have programs using OCaml" and it's like, yeah, that's the point of adding features to a computer program. Any computer program. Because people already use the computer program and it will be useful to them.