I think you're missing the point we're trying to make. Your script is only good if no other scripts are running except ones that USE your script and know how to work with it. If a user loads any other script that uses /set, the script will probably not work because of your script. It doesn't matter that your script tells the user that the variable was renamed with (2) or whatever. You specifically said that your script is designed for users without scripting knowledge. Such a user wouldn't be able to change their script so that it calls the (2) version of the variable, so it wouldn't work properly.

Let's say you have:

Script 1 (# of people who joined the channel):
Code:
on *:join:#: { set %users $calc(%users + 1) }


Script 2 (# of people who used /nick in the channel):
Code:
on *:nick: { set %users $calc(%users + 1) }


* Yes, you'd normally use /inc here, but this is just a quick and easy to see example.

Ok, so your script is supposed to prevent Script 2 from breaking Script 1 since it used the same variable name. However, you have 2 problems here.

First of all, if Script 2's %users is changed to %users(2) when saved and then Script 2 does:

Code:
msg $chan # of users who changed nicks = %users


Then, it will display the number of users who JOINED rather than changed nicks because the SCRIPT still thinks that it's supposed to use %users and not %users(2).

That's just the issue with 2 scripts working against each other. The worst issue is that every single time someone joins the channel or changes nicks, a NEW variable will be created...

User1 joins: %users = 1
User2 joins: %users still = 1, %users(1) = $calc(%users + 1) = 2
User3 joins: %users still = 1, %users(1) still = 2, %users(3) = $calc(%users + 1) = 2
etc.

And, as hixxy pointed out, /var no longer works with your script installed.

You say that if you want the variable overwritten, that the script should just use -o. That's fine if the person writing the script plans to use your script and so uses -o everywhere or if the user of the script knows to change all of those /sets to have -o. Otherwise, your script will just break every other script out there.

It's a good idea, but a better solution would be to have your script check if the variable exists and then just tell the user that you're overwriting the variable so the user knows that it was overwritten and can ask someone about it if he/she doesn't know how to see if it's ok. Now, that's still not a great thing as variables are overwritten often in scripts. But it's at least not changing anything... just echoing the information.

The suggestion of using unique variable names is a good one and should always be done for global variables regardless of what you're doing. Yes, it is possible that some other script could use the same variable name as you are using. If it's unique enough, then that's unlikely, but it's possible. That doesn't mean you should really worry about it.

If you are really concerned about variables in your script being overwritten even if you have unique variable names, then set 2 different variables to the same value and whenever you get data from the variables, check both to see if they still have the same value. If not, output an error and halt your script. Then, if the script halts with an error, you know that the variable was changed by another script and you can look for the problem. If you wanted to take it beyond just a message saying:
Quote:

%variable was changed by a script other than myscript.mrc. You may have a conflict between myscript.mrc and another script. Halting.


then you could also have your script (an alias) check all loaded scripts for the variable name that you're having issues with and then you can be more specific in your output:

Quote:

%variable was changed by a script other than myscript.mrc. You may have a conflict between myscript.mrc and another script. Halting. The following script(s) may conflict with myscript.mrc: yourscript1.mrc, yourscript2.mrc.


You get the idea. Personally, I wouldn't do anything other than use unique variable names, but that's a possible solution if you really want to avoid problems without breaking all other scripts that are loaded.