I can certainly see the value, and problems, associated with trying to track the script/line number when trying to fix a buggy script. What I would suggest comes from my background in writing TCL (and something similar in Perl): When an unknown command is about to be processed, the interpreter calls a function called "unknown", which let's the script itself try to resolve the command, before trying something else such as passing the command on to the command shell for execution.
In mIRC, I can see this being implemented as a remote, such as:
ON 1:UNKNOWN:/echo I don't know command $1 $+ ! | HALTDEF
Where a HALTDEF would halt the default operation of mIRC trying to send the command on to the server. Additional identifiers could be set to indicate which script file and line number were being executed at the time.
I can see value in such a remote event in cases where you would want to build up a command and/or parameters.. for example, I have a script that handles certain RAW numeric from certain servers or certain groups enabled, but not others. I do this by building up a command like "VAR %cmd = OnRaw<numeric>" then use $ISALIAS(%cmd) to see if such an alias exists. If it does, the script executes it. If not, it simply moves on without doing anything.
With an ON *:UNKNOWN:... remote, I could simply try to call the alias, and in the UNKNOWN handler, either try to handle the situation, or simply ignore it and assume I've not defined a handler for this particular server connection.
I hope I'm being clear.. Re-reading what I wrote, I'm not so sure!
