but it still doesn't trigger when you use /window -c or /close, nor should it.
Actually, I'd think it should. That functionality has actually been suggested a few times before. As I mentioned, mIRC's policy *used to be* that /commands don't trigger events-- but frankly, that policy isn't really upheld like it was, nor is there any reason to.
Why shouldn't /close trigger ON CLOSE? I don't really see a reason. A window closed. There should be a centralized way to catch this occurrence. The change to make ON CLOSE work for channels means that clicking the x button triggers the event. Why is clicking with the mouse any different from typing a /command?
I don't really buy overriding builtin /commands to be a viable alternative. Sure, you *can* override /query, or /close, but there are more ways to /close a window (/window -c)-- you a) can't override them all easily, and b) the second you have 2 scripts running that both modify the alias, you're screwed. mIRC's event-based design is what makes scripts modular and robust. The answer should not be "override /query to trigger ON OPEN". That's a hideous hack.
by that very reasoning on SOCKCLOSE should trigger even when /sockclose is used
This is a pretty bad example, because /sockclose is actually dreadfully inconsistent w.r.t. the other /sock* commands, so you basically just opened a can of counter-argument-worms. Actually, by your
reasoning, /sockopen should not
trigger ON SOCKOPEN. Similarly, /sockwrite should not
trigger ON SOCKWRITE. Frankly, I'll bet neither of us think that's a good idea. The consistent thing to do would be to make /sockclose trigger ON SOCKCLOSE, like the other commands. But this is a conversation about ON OPEN, not sockets, so that's another discussion.
What about 'PM / Query Blocker' scripts?
I don't see the issue. "query blocker" scripts tend to be in the form:
ON ^*:OPEN:?:*:if ($nick == foo) halt
That generally means you don't want to open a query with that nickname anyway... Sure, currently you can override this with /query, but IMO the "backwards incompatibility" here is minor. Oh no, you can no longer open a query with a nick your script is specifically designed not to open queries with.
Also note that mIRC can easily mitigate this by ignoring /halt in the ^ version of ON OPEN if triggered by you-- that is to say, it won't halt if *you* open the window. That solves most related scripts (and gives you the current behaviour of overridability), while still being able to at least *trigger* the event.
The alternate form of these blockers is:
ON ^*:OPEN:?:*some banned phrase*:halt
This doesn't even pose an incompatibility, since $1- (and matchtext) should be empty if you trigger the opening of a window anyway.
I can't think of another form besides maybe flood control, but again, that shouldn't cause significant incompatibilities.