Searched and didn't find mention of this. To demonstrate, create script filename test456.mrc and put this as line #1:
alias test123 { echo -s Line $scriptline of $script }
now paste this line in your status window:
//echo -s first message | unload -rs non_existentscript.mrc | echo -s 2nd message | test123 | echo -s last message
in mIRC 6.16, you see in status window:
first message
2nd message
Line 1 of C:\mirc\test456.mrc
last message
in mIRC 6.21, you see in status window:
first message
2nd message
Line 1 of C:\mirc\test456.mrc
* /unload: no such file 'non_existentscript.mrc' (line 1, test456.mrc)
... without displaying the 'last message'. It appears to be caused by mIRC no longer completely ignoring the failure to unload a script filename that doesn't exist. However, 6.21 generates an error message showing the wrong location for the error. mIRC seems able to continue on doing some things, as evidenced by echo'ing the 2nd message and calling the alias, but then seems to belatedly notice the error as it returns from the alias, thus generating the error as if the problem were within the alias, and doesn't continue the script past that point.
Any alias or scripted identifier you use in place of test123 will cause the error message to show as if the error was in that alias. Using a built-in identifier like $version or $ial doesn't halt the script and generate the misleading error message.
Instead of having the unload command and echo messages be a single line pasted in the status window, I changed them to all be on separate lines of alias test789 below the test123 alias within test456.mrc. The error line changed to be reported as the line containing "alias test789". When I move the test789 alias to a different script, and put another dummy alias below the test123 alias, mIRC 6.21 reports that dummy alias's line as the location of the error. This part made it hard to trace down the bug, because not only was the /unload error halting the script like it didn't before, but it was reported in the wrong script file, and was also reported as being in the next unrelated alias located in that wrong script file.
