> As long as these errors are reasonably explainable.
> If a strange error only occurs when running nmap on an OS X server, 
> then it might be useful for the user to know that the OS X server 
> isn't able to service all connections properly due to a bug in the 
> operating system.

It might be useful to find whether this is tracked somewhere.
For the record, here (comment #10) is a code which should reproduce this problem:
https://bugs.launchpad.net/zodb/+bug/135108
As for what asyncore should in this case I think it should theoretically be safe for accept() to return (sock, None). What usually happen after that is that the socket object is passed to another dispatcher subclass (the handler) and the connection gets automatically closed once recv() or send() get called on the next async-loop.

> Perhaps it's time to add an alternative handle_accepted(sock, addr)
> which relieves the user from calling accept() :))

This sounds like a very good idea for 3.2.
As for 3.1 and 2.7 (2.6?) I think it can be useful to suppress EWOULDBLOCK/ECONNABORTED and return None instead.
Considering accept() can *already* return None it wouldn't break backward compatibility.