In what ways is it unreliable? You're notified when a child is stopped, terminated, or continued, and you can make it so that you're only notified of termination using SA_NOCLDSTOP.
How is `pidfd` better, why would you use it instead of a SIGCHLD handler writing to a pipe?
Imagine you are a library, that needs to fork (and exec, of course) some children processes to do its work. Since you're a library, you can't just set a SIGCHLD handler (for instance, the main application could have set SA_NOCLDWAIT for itself, and let's not even get into the question of which thread will actually receive the signals). Polling waitid(2) for each of them would require a separate thread per child process, unless you can put all of your children, current and future, into a single separate process group — which you normally can't. I guess you could try to use a single thread to do waitid(2) with WNOWAIT for all children processes and filter out only those you're interested in... but you probably will keep getting the one you're not interested in over and over again, until the main thread will reap it. There are some improvements to this I can think of, but honestly, all the traditional waitXXX(2) functions simply are not properly composable.
How is `pidfd` better, why would you use it instead of a SIGCHLD handler writing to a pipe?