Kqueues and fork

Right now, kqueues fds are marked as not D_PASSABLE, which means that
the corresponding file descriptor is not copied into the child filedesc
table on fork. The reasoning is that kqueues work on file descriptors,
and not even files, so they are tied to the fdesc table.

As a curious coincidence, I have two private discussions last week,
where in both cases people were interested in getting more useful
behavior on fork from kqueues. [My understanding is that epoll does
that, so there is a desire to make kqueue equal in the capability.]

I convinced myself, that indeed kqueues can be copied on fork.
Precisely, the proposed semantics is the following:
- fdesc copy would allocate a new kqueue as the same fd as the existing
  kqueue in the source fdesc
- each registered event in the source kqueue is copied into same event
  (for the same filter, of course) into the new kqueue
- if the event is active at the time of copy, its copy is activated
  as well

The prototype in https://reviews.freebsd.org/D52045 gives the naive
implementation of the idea.  What I mean by 'naive' is explained in the
review summary, where I point out the places requiring (much) more work.

The new copy behavior is requested by the KQUEUE_CPONFORK flag to
kqueue1(2).  Existing code that does not specify the flag, gets the old
(drop) action on fork.

Example of the usage is provided by https://reviews.freebsd.org/P665.

Before I spend a lot of efforts into finishing this, I want to discuss
the proposal:

Is this what the app writers want?
Is there some reasons for the proposal to be either architecturally
unsound, or containing some hard to overcome problems?