> What would we do about all of the processes that fork but don't ever exec?
I speculate it isn't common, or at least it isn't required for ordinary desktop apps. Windows survives without fork().
> And isn't posix_spawn implemented in terms of vfork, which a lot of people like even less?
That sounds like a glibc implementation detail, not something required by the standard. I'm not an expert however. Simply, again I come back to: Windows can spawn processes without using it as an excuse to overcommit.
> I speculate [fork] isn't common, or at least it isn't required for ordinary desktop apps.
From a science perspective, the ability to fork is really convenient for parallel processing. Load some data and then fork a pool of worker processes, and they can all read almost free copies of that data. This is much easier than setting up shared memory. It's a bigger deal on an HPC machine with 128 cores than a laptop with 8 cores, but even on a laptop it's a significant point in favour of Linux.
Getting rid of it in Linux would also be going against Linus' rule that the kernel never breaks userspace.
Windows is a terrible OS, especially for servers, so pointing out that it doesn't have something isn't really a great argument for that thing not being very important.
Windows is proprietary and until recently, not very scriptable. None of that is relevant. We're talking about desktop users having their session killed.
I speculate it isn't common, or at least it isn't required for ordinary desktop apps. Windows survives without fork().
> And isn't posix_spawn implemented in terms of vfork, which a lot of people like even less?
That sounds like a glibc implementation detail, not something required by the standard. I'm not an expert however. Simply, again I come back to: Windows can spawn processes without using it as an excuse to overcommit.