I think the challenge will be how to convert existing C FFI/stubs to work correctly with code that wants to take advantage of multicore(domain) capabilities.
i.e. previously some code could've in theory assumed it only ever gets called by one thread at a time due to the global lock (and that lock would get dropped in a controlled manner by the usual released/acquire). I don't necessarily mean just global state in the C stubs (I don't recall seeing many of those), but implicit global/shared state in the C functions called.
Reading manpages will usually tell whether a given function is safe to be called (or when not there are sometimes _r variants that are).
This is no different than when writing regular multithreaded C code, one has to be more careful about what functions they can safely call. (and in fact current OCaml code can already be multithreaded, so if the C stub was meant to work correctly with multithreaded OCaml code with C->OCaml callbacks then it should've already taken necessary precautions).
I like the approach taken wrt to backward compatibility of sequential code though: only code that wants to take advantage of multicore will need to audit its C stubs for safety, if you don't use multicore everything will work as before.
How do you recommend to find these kinds of multicore-specific bugs in existing (or newly written) OCaml-C stubs?
Would tools like parafuzz help here?