Why? Because someone can make to directories of mirc, one in: C:\mIRC and another in C:\mIRCs and to run them simultaneously. So correctly will be that the identifier will look at this process of mirc where is running from.
This is where I think things get complicated, and partially why mIRC should stay out of trying to implement this.
It seems to me like your expectation here is that mIRC would allow multiple instances if they come from different copies of the mirc.exe executable in different paths-- but it's unclear that this is how such a feature would be implemented. In other words, you may end up not getting this behavior were it to be implemented. Khaled may decide to check the window class, or a number of other properties, that don't necessarily correlate to the path on disk. Alternatively, if you *did* get this behavior, it may be confusing to
other users who expect a single mIRC instance across all exe copies on their system.
If the argument is that each copy of mirc.exe runs a different set of scripts and therefore should be separate instances bound by separate instance checks, you're going to run into even bigger problems, since the same mirc.exe executable
can be used to run different scripts (by passing in command line arguments to point to a different mircdir, for example). Does mIRC allow multiple copies of mirc.exe to be run but not the same mirc.exe pointing at separate mircdirs? Does mIRC do a check across all processes to see which $mircdir is being used to determine if it matches the total process count? These questions don't have a "right answer", they can be interpreted in many different ways depending on different usage patterns.
Basically, this road is windy and complicated. I don't think implementing this is as straightforward as you expect it is.
