I can't remember why, but I faced a simple case where I
could use two -uN global variables to solve the problem, I
could have used /set (probably what I did anyway).
/set is fine, but if every suggestion were to be rejected because you could do it another way, mIRC wouldn't be what mIRC is, with the pros and the cons. Now when I faced the problem I simply thought "Ok it would make sense to be able to use -gu", I tested it and it wasn't working, and voilà. Not only it would make sense to have it, but as said it would improve the command.
priorities should shift to favouring more stability unless there is a significant advantage to a new behaviour.
Noone ever suggested that this should be a priority, I actually still have several suggestions that I'm waiting for, that are much more important than this one, it's not a reason to stop making suggestion
It's easy to say "it's a small change, it will barely have any impact, so there's no reason to oppose it", but at the same time, it's small features like this that end up causing major bloat in languages/APIs down the line
This is probably where we disagree with you, I don't think such an addition can be called "major bloating the language", can you give an example of a bloat in mIRC? It's not because there are multiple way of doing something that it is a bloat, imo.
Knowing you are against var -g, I'm not trying to convince you, but it looks unfair, obviously you don't want -gu/n.
I don't judge a feature by how simple it is, but how useful it is
Fair enough but as I said -gun would be in continuity of var -g, for convenience, of course I admit people wouldn't use that very often, just the same a lot of others things are rarely used in mIRC.
