You have to fork, it's the only way to make a new process. Now exactly which process does the fork()ing is, somewhat, academic. Some might argue about the band aid approach of the requirements of parenting and process groups; but that would require leaving POSIX (and hence source compatibility) behind. Allowing any process to set their own parent, process group, or controlling terminal without very strong bounds is dangerous; kind of like having Erlang with mutability, it's possible but it breaks the model (and all the cuspyness that comes with it) and leads to bad juju.
Requiring init to spawn the final daemon process (and hence getting the pid from fork()) is a red herring, any process can get a list of its children and query their proc structure (modulo permissions, but most sane people run init as root).
init should be as small as possible to do only what it is required to do; this is simple anti-fragility at work. The less code and state the better. Feel free to stick your process manager, dependency calculators, and helper daemons in other processes. init should be able to handle something as catastrophic as a SEGFAULT and just execve(/sbin/init) and just carry on (while logging locally and remotely of course).
Requiring init to spawn the final daemon process (and hence getting the pid from fork()) is a red herring, any process can get a list of its children and query their proc structure (modulo permissions, but most sane people run init as root).
init should be as small as possible to do only what it is required to do; this is simple anti-fragility at work. The less code and state the better. Feel free to stick your process manager, dependency calculators, and helper daemons in other processes. init should be able to handle something as catastrophic as a SEGFAULT and just execve(/sbin/init) and just carry on (while logging locally and remotely of course).