fork is not friendly to concurrent programming: fibers/threads/callbacks - what should you do with all this after fork?

While it is possible to create and manage some rules, it is simpler not to fork at all.

Yes. Fork was a clever hack for one point in time, back when processes were simple, single-threaded, and lightweight. It's always had the misfeature of inheriting resources which you didn't ask for. Not including it makes it mildly annoying to port existing programs, but 99% of the time programmers want spawn and are forced to build it from fork(), not the other way round.

AFAIK fork() is specific to UNIX and its descendants; DOS, Windows, and many(most?) other OSs don't have it either.

Sure, but an OS that self-describes as "POSIX-like" would be expected to follow the UNIX approach to things.

POSIX-like, not entirely POSIX! There are basic IO syscalls, and some process management calls, but overall I try to take unix as a guideline rather than trying to reimplement one entirely. I also try to take inspiration from other kernels (like fattr (which is equivalent to GetFileAttributes from WinNT), and spawnv from DOS/WinNT).

I guess I should reword it :/

Google's Fuchsia has a similar approach to Posix (no fork, signals, etc). Maybe some of their wording would be of use?

https://fuchsia.googlesource.com/docs/+/refs/changes/56/1013...

That's fair. And to be clear, reading "POSIX-like" makes me expect it to act like a unix, but that hardly means that you should be bound to follow that exactly:) If you wanted to set expectations a bit, maybe "partially POSIX-inspired, with other influences from $FOO and $BAR" would be clearer?