I'm sure this has been mentioned in either of the posts you referenced (but did not link to), but mIRC is not thread-safe, meaning the solution is not simple at all.
As much as you may think just creating a new thread and letting the scripter deal with thread safety will be a good solution, that will never work. Your assumption is that K can just create a new thread and that existing mIRC commands will continue to work fine in the new threads-- but they won't. Even simple things such as /echo probably has a nifty race condition somewhere. A scripter cannot manage his own thread data if the very commands the scripter uses have their own threading bugs.
Most of the data relevant to scripting is statically allocated in mIRC's data space (event info, data read from the socket, current connection id)-- meaning it would be like trying to multithread a singleton class in Java, if you need an analogy. For instance, lets assume for argument sake that mIRC stores the active cid in some global variable called "int active_cid". If I spawn two threads performing a /scid command on respective connection ids, there is an obvious race condition there, and there is nothing the scripter can do to stop it.
This is the design mIRC has (unfortunately?) chosen. It is not threading aware. The entire language would need to be rewritten with threading in mind-- and that is highly unlikely to ever happen (in the near future) given the enormous amount of work that requires...
I would suggest stop beating a dead horse and just deal with mIRC as mIRC is. There is nothing wrong with
event oriented programming. Not only is it the way things are done in the Windows API, but Tcl already uses such a design (
http://wiki.tcl.tk/1772) and does so successfully. I think this issue really comes down to a lack of understanding of the power of event-loops. They're far safer, far easier to use, and when performance is not an issue (it definitely is not in mIRC script) are a much better design choice. Java may have a great threading model, and Haskell may have amazing Monads-- but this is mIRC. In mIRC, "threads" are /timers as you very well pointed out-- there's no need for the "actual threading" part.
