Thinking more of it, it looks like loosing queued data just on socket close is too bad. It is normal to send the last bit of data and close socket. I am going to look into letting the async complete in this case at once.
WRT the other option suggested in the bug (checking if the data can't be sent without partial write), I don't think there is any other option than storing the data and sending in the background. If we could detect short result before actual send it wouldn't help. A few MB size send can't ever be sent on Unix without partial send() and we can't always return EWOULDBLOCK for such attempts.