>There is no purpose to limiting the size of the backlog, 

But there is. USTLing says that it to 1 seems to have a real purpose.


>which is, after all, just a kernel constant, just to fullfill the notion that
>SOMAXCONN has to have a "purpose". Limiting that size so that admins
>have to recompile their kernels just so that SOMAXCONN "does
>something" is not reasonable.

You have it completely backward.

>In the new world order, SOMAXCONN just ends up being a convenient
>default for the average application under average circumstances.

Nope. It's an upper bound on the backlog for whatever applications use
it as 2nd argument to listen().  The problem arises when the syadmin
decides that the system-supplied value of SOMAXCONN is "too small" and
bumps the conrresponding sysctl.  Which has no effect, since the app
asked for no more than the system-supplied value of SOMAXCONN.

Besides, if you really want a "default for the average applicaiton
under average circumstances", then empirically a number between 5 and
10 would be a good value. (If it weren't, we'd have a slew of PRs
about inetd, talkd, nfsd, and sendmail dropping connections).
It's only potential pigs that need the larger backlogs and which
might, reasonably, use SOMAXCONN. 

SOMAXCONN used to be a static limit for both the kernel and user code.
Now we make the in-kernel maximum backlog tunable via sysctl.  Then,
there's a consistency argument that SOMAXCONN should reflect the
maximum allowable value for the dynamic sysctl variable.
Doesn't that seem compelling?

If you really want a default, I'd add 
	#define SODEFAULTCONN 10

in sys/socket.h with the appropriate namespace protection, and advise
app-writers and pkg-importers appropriately.  

(nb: 10 is just what inetd now uses).