In general, since a server has the untagged EXPUNGE mechanism to indicate what messages it has expunged, there is little/no need to send a NO for an EXPUNGE command.
Many clients do an automatic EXPUNGE before LOGOUT when they quit, so you should consider whether you really want to send a NO, thus causing an error message in the client. If the server can not expunge due to simultaneous connections, but wants to "remember" to do it later in a deferred expunge, what it should do is as follows: Make the deleted messages become "invisible" to the session and send untagged EXPUNGE for each such message, marking the message with an internal "invisible" flag. Other sessions, in seeing that a message has become "invisible", should send untagged EXPUNGEs for such messages and render them invisible as well. New sessions should never see the "invisible" messages". When the last session that had the message "visible" has announced an untagged EXPUNGE (and thus the message is invisible to everybody), then the message can be expunged for real. The above strategy is fully compliant with the IMAP specification, and avoids access problems when a message has been expunged but that fact hasn't been announced yet due to the limitations on when untagged EXPUNGE can be sent. So, I'd argue that this *is* the way to handle multi-access EXPUNGE.
