If you think discussing thread-safety is "philosophical" than you're sorely mistaken.
It is ABSOLUTELY possible to implement thread safety in unsafe environments
It is, but only when the methods you use to implement thread-safety are in themselves thread-safe-- the same way you can't build a sturdy house on a foundation of mud. Nothing you can use in mIRC will be thread safe, as mIRC shares everything. You seem to be suggesting "just wrap every command in a lock and you'll be fine".. you won't end up with any threading at all, just one big lock wrapping every single command leading to an effectively single threaded system.
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.
This is assuming that the "simple" act of creating the unique hash table will not have any race conditions.. does it? I don't know. Does that mean using /hadd will avoid any threading issues? Probably not.
Output commands would be simple as well. Just run them in whatever the active context is.
Again, assuming the output commands are themselves thread-safe, which is not guaranteed.
Your performance claim is bogus. Threading will not solve much of mIRC's problems with speed. Again, look no further than Windows itself, which performs very well in terms of windowing vs picwins and does so in a completely single threaded environment using event loops. Why is it fast? Because the core codebase is fast. Threading would not make it that much more efficient than it is. If you really need performance, use DLLs.
That is one of the most enjoyable parts of programming: given a simple environment, construct the tools you need.
Again, mIRC gives you dlls. One of the most simplistic environments. Feel free to construct all the low-level threading tools you need using that if you truly understand how to solve the problem. Having K Implement a half-assed threading model in which the scripter is responsible for all context control would be more detrimental than helpful to the average scripter. If you believe yourself to be more advanced than the average, well, DLLs should be no problem to you, then. By the same token, if you can't handle DLLs, you probably can't handle what is involved in proper threading, either.
PS.
There are no licensing issues with DLLs-- no more licensing issues than with a plaintext script file. Any licensing you choose to use on *your code* is your decision. This would work the same way for any .mrc, .ini, .txt, .bmp file you distribute, ever. DLLs are also no more large than unwieldly script files. Those are, again, completely bogus claims.
