now as a matter of fact, you _can_ use all of those mirc identifies and variables with any irc commands, when mirc solves them before being sent to the server..
so at least some manually initiated command like
//raw ison $me
//raw ison %honicka
or
//raw ison $hget(orgchans,hownnick)
worked for me when i tested some things like that for purpose.
and as you might have guessed by that i dont really like to initiate things like these manually ex. every time i wanna know when someone is online, so i wrote me a script for doing so automatically (which actually has different notify-lists & -settings for the different irc-networks i'm on. why doesnt mirc already have integrated something similar after all those other multi-network stuff and commands it has gotten by now ?).
however, commands like those above work just fine in a script as well, so they should as well when using an ON UNOTIFY remote (they actually do and i dont see why they shouldnt).
one thing possibly following to not-using $mnick for the unotify would be to build up a script where ppl would have to replace some dozens of placeholdings with their own nick.
stupid enough, so another one is when you'd just set up some variables or network-specific hash table entries for your own nick, which wouldnt change like $mnick when you manually change your nick after connection, and let the script read out those variables/hash entries, so there'd be no need to bother about $mnick or people/authors giving away their nicks or other data with a script to be distributed, and it would even greatly improve its personalizationability.
(who'd do that anyways.. script without such 'per-user' varials..)
in addition to that, i'd say that mirc might approve again, if you'd add that function to its basics. sth like a 'third nick', which 'mainly' would be handled like the actual 'main nick', infact it should be called the real 'main nick', but which wouldnt change in any situation, so ex. an on unotify (like the one described above for 'taking back' a nick) could rely on that nick instead of the 'main nick' we knew yet, which isnt really a 'main nick' when it comes to changes. there's an 'actual nick' which we now dont really see of if its the same as the '(main) nick' saved in the mirc.ini or its just the temporary nick somewhere, because when the (runtime) 'main nick' changes, the 'nick' known by the field in the options dialog changes from 'main nick' to 'actual nick', and that looks wrong to me.
so there should be separate settings for 'actual nick' (which can be inserted to be used as the first tried nick on a connect), 'main nick' (which would be either the same as 'actual nick' or the other way round if one of them is missing, and would never change when specified by user even on a nickchange by force or the clients unability to connect by one of the others, or if not specified by user it'd be handled the same when a connection is established), and 'alternative nick' (the same we know already. basically to prevent the client from not connecting at all when a nick is already in use, as well as to provide a third nick identifier usable in a script or manual command. but this one's not really needed anymore then to solve any problems concerning nicks, notifies or any of their identifiers.)
i hope that's not been too confusing.
but i would really appreciate it if mIRC had some kind of multi-server property or transduction integrated for the notify-list, because when one uses that built-in notify its not very helpful to have it being cast on all networks the same time ignoring wheather i want to know if that specific nick is on that (un)specific network or not.
ex. i want to know if 'sparky' is on 'euirc' i just add 'sparky' to the built-in notify but i cant specify the 'euirc' property, and then the notify shows me all 'sparky's on all the networks i'm on. thats seems not to be too well-elaborated to me either, or they just didnt implement it yet for whatever reason there may be.