It's just a musing on the lines of "it would be great if Unix was designed differently than it is".
The problem with PIDs is that they live in a global namespace where they could be reused for another process, and it would be nice if
fork() returned in the parent some kind of handle that would be guaranteed to always refer to the child process, and that it could pass to other processes via inheritance or unix sockets /
See also the discussion here for a recent effort to "fix" that in Linux, including adding a flag to
clone() which will cause it to return a pid-fd instead of a PID.
But even then, that would not eliminate the need for that self-pipe hack  or better interfaces, since the signals notifying a parent process about the state of a child are not the only ones you would like to handle in the main loop of the program. Unfortunately, things like
epoll(7) + signalfd(2) on Linux or
kqueue(2) on BSD are not standard -- the only standard interface (but not supported on older systems) is the much inferior
 Preventing the PID from being re-cycled by the time the
waitpid() syscall had returned and its return value was used could probably be achieved on newer systems by using
waitid(.., WNOWAIT) instead.
 I would not comment on D.J. Bernstein claim that he invented it (sorry for the apophasis ;-)).