> How different is the behaviour of one of these calls to using dup(2)
> on an unbound/unconnected socket?

It's the difference between dup()ing a fd open onto a file versus
opening a new fd onto the file.

It's the difference between dup()ing a socket versus calling socket()
plus a stream of setsockopt()s (and maybe others - what else, if
anything, is yet to be hashed out).

> Is there some reason that dup(2) shouldn't work as desired here?

Yes.  You said it yourself:

> In the case of dup, the usual problem is that it just creates a new
> reference (fd) to the same file
(socket, not file, in this case)
> as the original fd.  By this line of thinking, creating a
> socket_dup() or even dup_socket() seems like a confusing path to
> take.

Only if you name it in a way that suggests dup() has anything to do
with it.  Think shallow copy versus deep copy.  ln -s versus cp -r.

This is not to say I totally disagree with you.  Encapsulating socket
options into blobs is an attractive approach to me as well, and, as you
point out, it gives abilities not available via socketclone() or
whatever is the principal call under discussion here.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B