But, as I keep trying to explain, using /tokenize with no parameters is not errant code, it's a valid use of the command. My point about it not being a small error is that it's not something that you can do without thinking. You might get the parameters mixed up or even forget one, but you can't forget both parameters for the command.

If it's ignorance of the ways of mIRC, well that's hardly within mIRC's capability to second guess everything the scripter does.

eg.
Code:
ON *:TEXT:!help:# { 
  msg $nick HELP INFO | tokenize | parameters: <delim> <text>
  msg $nick Description: tokenizes text based on a delimiter
}

* Error: You may or may not have meant to create an event hook. 'on ...' creates an event hook in mIRC script.
* Error: You may or may not have meant to trigger the command 'msg $nick HELP INFO'. Newlines delimit commands in mIRC script.
* Error: You may or may not have meant to trigger the command 'tokenize'. Pipes delimit commands in mIRC script
* Error: You may or may not have meant to trigger the command 'parameters: <delim> <text>'. Pipes delimit commands in mIRC script
* Error: You may or may not have meant to trigger the command 'msg $nick Description: tokenizes text based on a delimiter'. Newlines delimit commands in mIRC script
* Error: You may or may not have meant to end the 'on TEXT' command block. Braces surround command blocks in mIRC script.

My point is hopefully obvious. At some point an error is going to be undetectable from genuine code. Error messages provide a way of finding, well, errors. They're not there to perform an on-the-fly scripting tutorial or give a running commentary on the state of the script. /tokenize without any parameters is a valid command, and as qwerty showed it is intentional.

Spelling mistakes, grammatical errors, and stupid comments are intentional.