argv0: This is essentially the same argument you brought up that lead to the philosophical discussion in the other thread. The only purpose it serves is to propagate further misunderstanding. It is ABSOLUTELY possible to implement thread safety in unsafe environments, with the proper application of locks. It is not the language's job to provide a perfect environment for threads.
Having threaded a 2K-line singleton class (a filesystem, of sorts), I can safely say it's fairly simple. All the access to the data was simply made atomic, so there could be no conflict without explicitly creating one.
MIRC race conditions can be solved in a similar fashion. To use your example of the active cid, and in fact anything else, a scripter could simply create a unique hash table containing all the variables they need. The thread could then access that hash table without worrying about race conditions.
Output commands would be simple as well. Just run them in whatever the active context is. Yes, this means some commands will run on different connections than they started. Aw shucks.
For more capabilities, feel free to design your own solution, such as sending a signal back to the main thread, which won't have access issues. That is one of the most enjoyable parts of programming: given a simple environment, construct the tools you need.
Moving on: Performance is indeed an issue in mIRC. Consider the number of scripts that focus on visual presentation. Should those scripts be forced to cripple the client itself for the sake of drawing a shiny picwin? Or should they be limited in artistic ability to preserve the client's functioning? Why should the designer even have to choose?
On another note, there are some algorithms that just don't lend themselves well to event oriented programming. There's no question that they CAN be converted, but it's not easy, and rarely optimal.
In conclusion, I see this as just another tool. If implemented, I can imaging seeing threaded displays on picwins, faster responses on large scripts, greatly improved data processing abilities, and an overall increase in the possibilities mIRC script provides.
MPDreamz: Thank you for your useful solution. A cursory glance at the code appears to do exactly what I'd like. I'm not sure about the details of its use, but it looks good.
However, in my opinion, DLLs are still not an ideal solution. This goes not just for threading, but most other applications as well. They are too large and unwieldy to easily distribute with a script, and in some cases face licensing issues.