Although Unix was not designed for multi-processors originally, its main run-time abstraction (process networks) is easy enough to port to any platform with a c

Although Unix was not designed for multi-processors originally, its main run-time abstraction (process networks) is easy enough to port to any platform with a common store. So there's not much to discuss about single-core vs multi-core, it's either one VN or multiple VN machines connected to a single abstract memory. Remove the shared memory, then issues start to rise. You say "radical ideas tried" but I believe that is not relevant. Radical ideas typically don't fly because they are radical. However you can already see things happening that are not radical but are breaking the Unix machine model very hard: - "accelerators": these are really fully fledged co-processors with their own local memory. There is no easy way to conceptually delegate Unix threads to accelerators precisely because they don't share the memory. (Now with recent GPUs the architecture was modified to actually share the memory between the CPU and GPU so things become possible, but not all "accelerators" have that feature) - on systems-on-chip you now have scratchpads next to cores on the architecture. Some cores may not have access to the "main" memory of another core (eg the radio controller in telephones) although they are fully-fledged cores as well. Because of this lack of shared memory, it is not conceptually possible to envision a Unix system where processes access these extra processors transparently. tl;dr there are already hardware architecture with separated memories and Unix can't cope with that easily because its main abstraction requires shared memory.