> This does not seem to work.

Yes, the proposed fix is buggy: the solution is to drain the output
buffer, guarding against recursive calls between send() and
handle_close() (patch attached).

> Note that after the first 'handle_close' has been printed, there are
> no 'handle_write' printed, which indicates that the operating system
> (here linux) states that the socket is not writable.

That's because you're closing the socket, whereas the original report
is dealing with half-shutdown connections.
Try this:
"""
 class Reader(asyncore.dispatcher):
     def __init__(self, sock):
         asyncore.dispatcher.__init__(self, sock)
+        self.shutdown = False

     def writable(self):
         return False

     def handle_read(self):
         self.recv(64)
-        self.close()
+        if not self.shutdown:
+            self.shutdown = True
+            self.socket.shutdown(socket.SHUT_WR)

 class Writer(asyncore.dispatcher_with_send):
     def __init__(self, address):
"""

This will behave as expected.
Calling socket.shutdown(socket.SHUT_WR) means that you won't send any
more data, but that you're still ready to receive: it results in a FIN
being sent to the remote endpoint, which will receive EOF on recv().
But subsequent send() from the remote endpoint will still succeed.
Whereas with socket.close(), you not only shut down your sending part,
but you also signify that you don't want to receive data any more: a
FIN will be sent immediately to the remote endpoint, and on subsequent
send() from the remote endpoint, a RST will be returned, which will
result in EPIPE (or, in there was data in the receive socket buffer
when the local endpoint was closed, a RST will be sent directly,
resulting in ECONNRESET).

I still need to write a test.