i coded the WASIX fork syscall, so I understand all this (f.y.i. I much prefer rust to C as its got a much better designed threading system).
what you must realize is that one does not have to use a syscall if they don't like it in (e.g. just use rust to code your app and it will never call the fork syscall)... but taking that choice away from others who want to use it is unfair as its denying them access to the WASM ecosystem (e.g. bash)
It looks like one can easily call fork() in an unsafe block from Rust [1], assuming it's provided by the target's libc.
OpenVMS for example does not provide fork(). What it does provide is vfork() by doing some internal book-keeping within the C run-time library and delaying the actual child process creation until exec() is called [2].
The POSIX specification eventually standardized posix_spawn() [3] as a partial alternative for fork() due to its numerous issues, some of which are detailed in the rationale section of its specification. Sadly, it appears its usage is not as widespread as it could be.
I'm not blaming the WASIX project for providing POSIX semantics since running POSIX-compliant programs is an explicit design goal. What I do wish is that more people realize that POSIX isn't the pinnacle of operating system interface engineering or some sort of holy scripture that shall not be questioned. It's 1970s legacy from long defunct hardware and obsolete software (think PDP-11 and Version 7 Unix) that was written down as a specification in the 1980s.
what you must realize is that one does not have to use a syscall if they don't like it in (e.g. just use rust to code your app and it will never call the fork syscall)... but taking that choice away from others who want to use it is unfair as its denying them access to the WASM ecosystem (e.g. bash)