I'm not an OCaml programmer, so much of this document goes over my head, but I have done a lot of thought about multi-core and multi-thread processing. It seems to me (and this is along the lines of your document, if I'm reading it right) that the best way to do this is to make all sharing explicit.

On a single core, pre-emptive multi-threading is a bad idea because state is necessarily shared, which means that programmers need to be very careful and usually get it wrong. A co-operative threading model is the right model here because writers can rely on a single thread abstraction for writing code, but can then yield off to other "threads" to keep the core busy. This requires no context switching overhead, but it does require that all I/O is asynchronous.

For multicore processing, again, threads are generally a bad idea, not only is state shared, but now it has to potentially cross NUMA nodes implicitly which again is a terrible idea for performance (and performance debugging).

The model proposed sounds like a good one, with an explicit shared state and a "context" (per cooperative thread) local state.

My biggest fear is the idea of "auto-promoting" objects from local into shared state. This means that either the compiler will have to implicitly lock everything in the shared state for concurrent access, which will lead to correct code and potentially poor performance (e.g lockless shared data structures are not possible) or, programmers will need to take care to lock everything themselves which we all know has worked out really well in terms of correctness.

My suggestion would be to make (potentially through language annotations) two new kinds of allocations, shared synchronized allocations, and shared unsynchronized allocations and to ensure that no pointers can cross between any of the three memory regions.