To be wholly clear about the issues, it's not with asyncore, the core asynchronous 
library, it's with asynchat and the internal changes to that.  Any changes to asyncore 
were to fix corner cases and exceptions.  No API, internal or external was changed.

People who subclassed from asyncore should have no problems.  People who subclassed 
from asynchat may have problems.

If we want to revert selected changes to asynchat, that's fine with me.  AFAICT, there 
is only 1 substantial bugfix in asynchat (if your text terminator isn't discovered in 
the first ac_in_buffer_size bytes read since the last terminator, your connection will 
hang), which is easily pulled out.  Offering a compatibility mode is also relatively 
easy.

Six months ago you were 'eh' with what was going on with the asyncore libraries (see 
messages from early October).  Over a year ago everyone on python-dev cared so little 
about the libraries that it was preferred to give me commit access than for someone to 
review the code.  Now everyone seems willing and happy to remove the library because it 
is "unsalvageable".

Ultimately the change that broke Zope/medusa was replacing the use of asynchat.fifo 
with a deque, and getting rid of ac_out_buffer.  Those are *tiny* changes that we can 
change back, temporarily pull into Zope, and tweak Medusa to fix (I'd be happy to offer 
a patch to AMK to produce Medusa 0.5.5).

As for your "subclassing is bad" comment, Twisted, wxPython, SocketServer 
(SimpleXMLRPCServer, TCPServer, ...), sgmllib.SGMLParser, etc., all use subclassing as 
part of their APIs.