To answer your questions:

1) Technically, returning an error might better.  However, the point
   here is that servers already don't check for errors.  If you change
   the definition of blocking accept(2) to make this okay, then you
   have to change everything that uses it.  If every server has to be
   changed, then: a) you're still going to have this problem (at least
   with some servers) next year, and b) you might as well have told
   them to use non-blocking accept(2)s.

   All servers have to already deal with the case of a socket being
   closed quickly after it's accept(2)ed; if they don't, then they're
   broken in other ways.

   (Or, to phrase it another way: Gee, don't you think we considered
   that??)

2) While it perhaps makes little difference, I considered allowing the
   Linux behaviour of returning embryonic connections -- in which case
   sofree() would not clean items on so_q0 either.  It seemed better
   to make the soclose() behaviour symmetric so that this doesn't get
   mysteriously broken again in the future.  It's certainly not
   harmful either way.

3) I think that's true.  Another change I was considering was to have
   the protocol stack guarantee that the peer information was always
   available to accept(2), so that the server always knows who a
   connection attempt was made by.  This would require some additional
   interface changes, though.