In order to have even a remotely legitimate chance at multithreading support by mIRC, the language would have to be, or at least simulate the actions of a compiled language as opposed to a scripting language. Just the shear spread of aliases, inputs, outputs, and changing of variables amassed throughout anyone's mIRC directory would make multithreading near impossible unless threads were given free reign over all. Simulation of a compiled language would make it a lot like java, slow as hell and bloated. Actually being compile-able would require an extensive re-work of the language itself and how it is run within the mIRC application.
For example, I have a huge file, Lazy.mrc, which basically shortens a bunch of alias calls to one or two letters, as well as several common channel type aliases. If I were to look at my Guest ban script, I could easily see that the two files would have to be very interlinked just from the amounts of simpler aliases I call. You may say that "oh you can just use the full command," but that's not really a solution. Those of us that actually do divide our scripts into multiple files to keep them organized, would have to either re-include functions from another script file or use something like the "use" or "include" functions found in Perl and Python in order to incorporate all that any script that was to be in a thread needed.
A simpler solution to the multithreading would to just have mIRC itself, and not the scripting language, be either multithreading or make use of dual core machines inherently. This way, mIRC would control the threads, the interlinking of the memory spaces, and the numerous other difficulties that arise in multithreaded programming in languages like C/C++ for us instead of having the script writer try to intricately plan out his threading maneuvers carefully so that they don't explode violently.
Only thing I can see that multithreading within the mIRC scripting language would assist on is allotment for either really huge while loops, or infinite ones, but these types should be worked around anyhow. Speed isn't generally a problem, if you're that worried about it you should be using hash tables instead of variables and SQL tables instead of .ini or .txt files, as both these options are significantly faster than their counterparts. For example: to open, search, and close an SQL table as opposed to opening, searching, and closing a flat file of the same data there is a ~150x speed difference, the SQL table takes a measly 2ms while the flat file took a good 234ms. Hash tables are similar to SQL tables, but not as fast, just faster than accessing the internal mIRC variables.
So… mIRC w/ multithreading.. I don't see it being a valid "update" as it can be worked around in so many more ways on the scripter's side just by using better scripting practices (no goto loops, no massive while loops to search a file, etc.) or even making smaller more efficient scripts, or of course, using things like hash and SQL tables instead of those ungainly .ini files I see everywhere.
