I think the main difficulty consists of two parts that affect each other. On the hand, you have to design language features and that requires some sound theoret

I think the main difficulty consists of two parts that affect each other. On the hand, you have to design language features and that requires some sound theoretical foundation (i.e., what does "multicore" mean, when programming OCaml). Then there is the profound technical challenge to implement these semantics in a performant runtime system. The thing is, single-core OCaml is actually pretty efficient, especially considering its relative (e.g., compared to Scala and Haskell) simplicity and elegance. People would not accept losing these properties. As an example, consider the straightforward implementation of a heap allocation in the single-core runtime: To allocate a small value (something that OCaml programs tend to do often), you just increment the pointer to the young generation (usually a 2MB buffer). Only when that fails, more complicated operations are triggered. Because it fails seldom and because the compiler can store the pointer in a register all the time, you don't pay very much for many allocations. If you want to do that for multicore, you have one obvious problem to solve: How do different cores communicate values that live in this young buffer? Do they share the same buffer? Then you'd have to coordinate access, wasting time. Do they copy the values? When? Could we infer shaded values and allocate them specially? Do we need type-system support? Etc., Etc. Languages that work on the JVM or .NET have it much simpler to answer these kind of questions because the answers have been built-in to the VM itself.