And let's not forget the Mac, which was a dead-end until 1997.

We've had an important change to computers since then in that essentially every processor you might be running an OS on will have multiple threads of execution available. As long as some thread returns to the OS and the OS there does a check for excess resource usage it looks like Fomos's model could be made to work. Except in the case where you have some task that uses more threads than the system has which then all try to grab the same lost mutex or something. But you could always just ensure that the OS has at least one thread at any given time, which could be pretty expensive depending on how many threads are available.

It is true however that we're in a different world now with multicore processors. Back then preemption was about slicing up the usage of a single sequentially executing core.

For very specialized (probably embedded, but maybe other) use cases, I can see the value of specialized operating system which dispenses with time slice scheduling within a core and just assigns waiting tasks to a free core when/if it becomes available. On systems with very high core counts, and with lots of short lived tasks, there could be some value to this.

Even back then, on many machines and operating systems it's not like the whole world stopped when a process would not give up time slice. Things like mouse cursors, keyboard buffering, and often even some I/O were able to proceed because the hardware assisted in making that possible.

The thing is, I don't think going cooperative simplifies much.. you still have to handle concurrent access to shared resources, and re-entrancy etc. By the time you've made your operating system able to handle that (memory, VM subsystem, I/O, etc.) from multiple cores... you may as well just go implement timeslicing as well.

I'm not sure what the advantages of this would be for something like a renderer for instance. Would synchronization be easier this way? I'm sorry for the disclaimer, but I must admit I really don't know and if someone answers I would like to forward my thanks

It's interesting because these days many language runtimes provide their own internal "green threads" / "coroutines" / "async", in-process timeslicing anyways.