Comment 7 for bug 1887913

There is no such thing as deleting a file descriptor externally. That is not a thing that can happen; the set of file descriptors (small positive integers) that a Unix process knows about is not directly impacted by a behavior external to the process. Specifically, in your comment "we delete the standard error file descriptor," no, we don't delete it, but we might observe that it has no reader.

So in order to talk about behaviors on write() failures we need to use proper terminology. I think what you're trying to say is that a writable object to which a file descriptor referred has ceased being writable. The nuance here is whether you're asking to detect EBADF (which the _descriptor_ itself is not valid - either it was closed or was never valid), versus EPIPE, where the target object (tty, pipe, socket), can not be written. If the latter, I suspect that the situation has changed now that SBCL does not intercept the SIGPIPE handler. (https://sourceforge.net/p/sbcl/sbcl/ci/1300c870)
So you might want to investigate installing your own SIGPIPE handler.
But overall I'm still unsure whether you're observing "hanging" (which would imply, say, doing a blocking write operation), versus seeing a Lisp condition which implies *not* hanging.

So there's really nothing actionable here; but in the future if you wish to report a bug against SBCL you should provide some lisp code, the expected behavior, and the observed behavior.