It would not require such drastic changes to mirc itself at all, you final paragraph is more along the lines of would be required (at least as far as just parsing signals off to the alternate engine).
However i believe it would require some significant tweaking/additions to the tcl engine itself. Just like eggdrops, xchat, ioftpd, and others, the tcl engine would need to be modified both to add event triggering and well as the ability to pull information from mirc internal identifiers (for more complex ones this would require its own interpreter to check and redirect identifier/variable calls from a tcl-like syntax).
It would instantly create a significant increase in effort to maintain the scriptability of mirc. I dont think its a good idea to implement it in a way similar to other clients.
However, something like what genius_at_work suggested could be quite useful. The ability to attach external scripting engines and a way for mirc to call a procedure/function and catch/retrieve the information. This could certain expand the the scripting engine by allowing scripters to offload something that mirc can not natively do or handle well but other scripting languages can (such as arrays).
