First some definitions:

* '''Process:''' A task that does '''not''' implicitly share resources (in particular: memory) with other processes (on the same system).
* '''Thread:''' A task that '''does''' implicitly shares resources (in particular: memory) with other threads (in the same process).
* '''Task:''' A process or a thread.

I believe that, in most situations, it is best to use preemptive multiprocessing & cooperative multithreading.

Because sharing resources requires more care with preemptive multitasking, the tasks should have to explicitly share resources.

(The hierarchy of having cooperative threads ''within'' preemptive processes makes sense to me, but I'm having a hard time putting it into words at the moment...)

If you have a good reason for needing preemptive multitasking, break your program into multiple processes (some of which may make use of multiple cooperatively scheduled threads) rather than making all your task switches preemptive.

Many operating systems could certainly make it easier to create & manage multiple process applications. e.g. Processes could be grouped into applications (or application instances?) &, rather than just showing a process list, be able to show an application list. Or a list of processes for a given application. Maybe some friendlier APIs for spawning & managing processes within an application?

''There are process groups on Unixy systems for this purpose, aren't there?  I suppose they don't nest though.'' Yeah, there ''are'' certainly systems that have "metaprocess" features. I guess I'm saying that such features are a good thing & shouldn't be skimped on.

Now, there are certainly exceptions, but this seems best for the general case.

----
Why have theads at all? CommunicatingSequentialProcesses are even easier than multiple cooperative threads.

''Ah! A very good question, & one ''I'' intend to investigate as time permits.''