Well, it wouldn't really be the /close command triggering the event, it would be the window closing that triggers it.
But the window closing in general shouldn't be an event; only the window being closed by the user should. For example, I have a lot of aliases that open a hidden window, load stuff in it, do something and then close the window (for example, sorting). Would you like an on CLOSE somewhere in another script to trigger for that too? I wouldn't. Calling /close isn't always the same thing as clicking on the X button.
I think that a scripter must always know that when he uses a certain command, only the things that he wishes to be done by that command will be done. Triggering an event by a command would destroy that sense of control and would make things unpredictable in many cases (imagine a command in that event calling another command, which in turn triggers another event etc).
A similar case is that of /window @blah and on OPEN. A custom window opening is certainly no less an 'event' than a custom window closing, the on OPEN doesn't trigger though. And this isn't a bug since the help file notes: "The OPEN event does not trigger for custom windows". The reason is that a @window can only be opened by a /command and since we (presumably) don't want commands triggering events, the on OPEN has specifically been made not to trigger.
Making commands trigger an event (directly or indirectly) isn't useless, but in most cases, it creates more problems than it solves imo. /exit could be considered one of the few exceptions, because it cannot be used repeatedly or be of any use for a specific scripting task. It can only be used once (usually at the end of a script) and has almost the same purpose as the X button. More important, closing mirc without other scripts knowing (so they can save their settings etc) is 'fatal'; so fatal, that the rule "a command cannot trigger a script" must be violated.
I just found out that /window -a also triggers the on ACTIVE event. I don't fully agree with that either, but I can imagine why this makes more sense than /close triggering on CLOSE.
I don't think adding a switch to /close for this would hurt anyone, nor would it harm mIRC scripting in general, imho.
It wouldn't hurt but it wouldn't be of much use either. I'm guessing that most of the times scripters feel the need for such an event because they want to monitor open windows (to update their custom switchbar for example): if a user types /close, they want to know about it so the switchbar is updated. I doubt that any user would include that switch when they type /close from the command line, thinking that this could be useful for some of the scripts they run.
Neither way (triggering or not triggering on CLOSE) is perfect, but considering the way mirc works in general, I prefer the second (current) way. If the first way is ever implemented, there should at least be a switch that would make /close work like it used to (ie not triggering the event).
