to remain consistent with the standard that it's adhered to ever since its introduction.
Show me where this "standard" is written. Implementation is not a standard. Implementation is an implementation *of* a standard. The implementation can be wrong or simply outdated. And in fact, with the change of ON CLOSE for channels, we've seen that this "standard" has in fact been changing over the last few versions.
the key difference with on SOCKCLOSE is that it is triggered in response to external stimuli
But ON SOCKOPEN is not. Neither is ON SOCKWRITE. They don't trigger randomly, they trigger in response to typing /sockopen or /sockwrite respectively. Sure, there might be a delay, sometimes significant, but it's not "external stimuli". The trigger is specifically coming from your end, namely the /sockwrite or /sockopen-- it can never happen in any other manner. There is an inconsistency here. Personally, I'd rather see things in the form of ON SOCKWRITE/ON SOCKOPEN, because they are much more useful.
a more common example is something similar to:
on ^*:open:?:*:%q = $nick : $1- | .timerq 1 0 $eval(%q = $input(Accept pm? %q, y), 0) | .timerq -e | if (!%q) halt
Sorry, no, I don't acknowledge this as more common. You're using workarounds to make things work when they should not-- ie. a /timer to make $input work even though mIRC does not allow modal dialogs in events (for a very good reason). Let these scripts break. We're not going to argue that maintaining backwards compatibility is more important than allowing for unintentional functionality.
a more pragmatic approach would be to introduce a new event prefix to have on OPEN/CLOSE trigger in response to commands
Extra prefixes are not necessary. I already proposed a reasonable implementation that preserves the functioning of "common" scripts (including the one above, although I don't consider it common). To repeat, /halt in a ^ event will not /halt if triggered by you. mIRC can implement an internal switch without affecting the usage. Whether you can /halt your own /queries isn't absolutely necessary. The real heart of this issue is simply being able to get a callback when you /query-- that's really all that's being asked for. In that sense, I think losing /halt on self-triggered OPEN events is a reasonable compromise. Probably not too hard to implement, either.