I played around to find a way to get the information of what the parser translate strings too, to confirm the list I gave earlier. Basically, what I did was the "opposite" way of doing an internal script -- instead of tricking the parser that I'm going to say something and allow execution of code in say(), I instead tricked the parser that the following simplified script will be executed while in fact being part of a say command
The code looks like this:
say(-1)
text(1,0,0,N+5)
(Simplified command to test)
say(5)
speak_active
endtext
endcutscene
untilbars
loadscript(stop)
N here is the amount of lines the translated string from simplified to internal scripting. flash, for example, is 3 lines (flash(5)|shake(20)|playef(9,10)), and thus N should be 3, and 3+5 is 8, so the line should be text(1,0,0,8).
Do note that you cannot test say() and reply() properly as the commands work with lines below. Also, I bet squeak(on|off) can't be tested also, as that's functionality that doesn't exist internally, but is executed from the parser itself.
This can be used to see what the parser does when it get bogus stuff (it *should* ignore it, but obviously doesn't always do it -- the internal-scripting-without-cutscenes method shows this).
This shows, for example, that the 2.1 squeak() command, which seems to be parsed differently from most other stuff, *ignores* unknown parameters and remove the command completely, instead of, like music(), sends the parameter to play() as-is.