There's really no such thing as "behind the scenes" with threading. Once you add threads to your environment you need a way for the script to synchronize them, it's far too difficult if not impossible to do automatically, especially for a crude interpreter such as mIRC.
Consider a script that relies on the results of a $findfile for a subsequent event-- a setup that in your system would run on two separate threads:
on *:TEXT:!count *:#:set %total $findfile($1-, *, 0, 0)
on *:TEXT:!report:#:msg # %total
If a user types !count and !report immediately after, mIRC will still be in a $findfile loop on another thread when it returns the total value. It will therefore report a wrong or undefined value. It's impossible for mIRC to synchronize this automatically, because mIRC has no way of knowing what data is being shared across threads. Only the programmer can possibly know the answer to that (and often even the programmer doesn't know, hence the complexity involving threaded code). It is therefore necessary for the user to give the user a way to synchronize this code. Setting %total to $null is not sufficient, because there would still be a race condition that could lead to corruption or data, or worse, crashing of mIRC.
If every command mIRC ran was immutable and stateless, it would be feasible to run (almost) everything in a thread. It is of course impossible to guarantee this with mIRC's language, since data is neither immutable nor stateless.
