I thought the point of vfork is that they do not share an address space. But there are other things still shared and they should really just have a CreateProcess.

no, fork creates a new address space, vfork doesn't

the posix_spawn mentioned in the article is effectively the equivalent of CreateProcess

Last time I looked, posix_spawn() just called fork/exec

That's an implementation detail at this point. The idea is to have a single syscall that takes all the information needed to spawn the process, and does so atomically, without the need to spread it across several calls. On Win32, that's CreateProcess(). On POSIX, the equivalent is posix_spawn().

In glibc it uses vfork() in some cases.

In Solaris/Illumos it uses vfork() or vforkx().

In principle posix_spawn() can be a system call.

On macOS it is a system call.

They still share an address space until exec replaces it for one of them. Particularly awful is that they share the same mutable stack which is a pathway that only leads to the inner circle of hell.

Assuming you call exec, of course. To not call exec after vfork is not an option; one of the many ways the fork family of functions are fundamentally broken.

Well, without undefined behavior you can also call _exit(), continue within the same function, and receive conforming signals. Unfortunately this isn't always spelled out and there's code out there that definitely does other work invoking undefined behavior.