Ok, I'd never thought of using -rv to swap vars files. I doubt it would be used much if at all, because of the effects it would have on the variables created by other scripts. But if it's an issue that all -uN or -e variables cease to exist, it should also be an issue that some normal global vars also cease to exist, or revert back to their value at whatever point when they'd been saveini'ed to disk.

To test this, I created both a normal global var, and one having -u99999 switch, then I used -rv to change the file to use an empty foobar.ini, and found that neither the normal or temp global variables were written to disk to the old file as I used /load -rv. I then tried to see how long it took for mIRC to write the permanent or global variables to disk, in an environment where the scripts editor wasn't opened and no scripts were executing the /saveini command. After 4 hours neither global variable was written. That is, until I used alt+R to open the scripts editor to the 'remote' tab without doing editing of the script, and immediately the vars.ini gets updated.

Unless you meant that someone would execute saveini to flush the vars.ini to disk prior to using load -rv, then planned to use load -rv again later to restore their variables. In which case they're trading one problem for another, because instead of missing/wrong permanent globals vanishing even though they existed for 4 hours without being written to disk, the /saveini now causes temp globals written in stone as if they were global, as well as the globals written in stone as if they had not used -u -z -e or -c. It would make sense that load -rv would trigger a flush to disk for the old filename, so the 4-hour-old permanent global can get written to disk, as this is similar to an EXIT event as far as the variables are concerned.

But regardless, allowing vars.ini to contain info about variables so ON START can accurately sort things out is nice. That new behavior would be the only way I know for discovering whether a global variable is using the -c or -z flags, as there are no .props to tell us.

Code:
//inc -scu5 %x | set -sz %z 5 | saveini


Since global variables are so important, there should probably be some kind of flag to trigger a disk write to the vars file, after a reasonable interval, if there have been global variables created or deleted. The -c or -z increments and decrements shouldn't need to trigger such a diskwrite, since the vars file containing a timestamp would let ON START accurately restore variables without the updated diskwrite.