Comment by cryptonector

Hah, that's pretty funny. Regardless of the motivation as written, the motivation I surmise is:

- some systems (e.g., Windows) lack fork() for various reasons

- vfork() is baaaad

- I know, let's do something like WIN32's spawn() or CreateProcess(), but, like, better

The middle item I have good reason to think is very likely. vfork() still has a bad rap from that old "vfork() Considered Dangerous" paper. That paper circulated a lot way back when, and was the reason vfork() was removed from some Unixes for a while (well, it was left as an alias of fork()) before it was eventually re-added. The Open Group participants would been very aware of that paper, and that is almost certainly the reason that POSIX says about vfork():

  Conforming applications are recommended not
  to depend on vfork(), but to use fork() instead.
  The vfork() function may be withdrawn in a
  future version.

So if fork() can't perform well, and the committee won't recommend the use of vfork(), what shall the committee do? Answer: design and specify posix_spawn(). It's not an unreasonable answer. Though, IMO of course, they should have un-obsoleted vfork().