Well, I guess /disconnect shouldn't wait since you have /quit if you want to wait and get the quit message sent properly.. But as far as /exit is concerned, there is no mention that mIRC will use /disconnect or /quit (really, their underlying behaviors) on connected server when /exit is involved, your reply says
When you use /exit, mIRC closes all sockets immediately, so a QUIT may or may not reach the server. There is no way of ensuring that QUIT has reached the server after an /exit without keeping mIRC open
But are you even sending a QUIT message when we use /exit? If you are, it's pointless if you purposefuly close the sockets right after
.
Note that this has nothing to do with /disconnect or /quit, it's really what /exit does which changed in behavior, before it would always get the quit message sent correctly, or was that just luck? I doubt it was.
I think that /exit should do a clean quit (/quit), first because it was the behavior for year (or so it seems, again I don't recall /exit ever ending up with QUIT messages not sent properly), but also because it makes more sense imo, there is simply nothing wrong with mIRC issuing QUIT messages, hidding/deleting the UI and only close once there are no more data to send on the socket(s). Currently, when you exit, it seems to the others users your internet connection is broken or that mIRC crashed when you just exited the cleaniest way possible, suggesting we should use /scid -at1 quit | exit if we want that (old) behavior is a bit ridiculous imo!
If this isn't going to change I think /exit should definitely get a new switch to issue /quit on those connected server.
