This *has* indeed been suggested before. Instead of wondering next time, use the Search.

I love suggestions that blindly tout "efficiency" as the motivation.. Do you really know the efficiency difference of a case switch versus an if statement, or a while loop versus a for loop? Have you implemented these features yourself in an interpreter and benchmarked the varying results? Can you provide us with said "more efficient" implementation as well as the benchmark results? If not, why would you claim it's more efficient? How did you come upon such a conclusion?

The truth is, for loops aren't "more efficient" and neither are switch cases-- those are just syntactic sugar, and mIRC already has enough of that.

The only thing that would potentially be more efficient from language construct support would be "arrays". But the thing about arrays is that they sort of already exist in various forms, most efficiently as string tokenization ($gettok on a %var) followed by the use of Hash Tables (hash tables are slightly less efficient than true arrays but probably moreso than dynamic variables-- this is an assumption, it could be the other way around but that doesn't really change the point). However, anyone who implies that arrays don't exist in mIRC doesn't understand what an array is to begin with. The only difference would be syntax in construct vs. function call-- again, not exactly a very good justification. I also can't vouch for the efficiency gain in switching from string tokenization / dynamic vars / hash tables to a builtin first-class array type because I have no way of benchmarking the results. Making such a claim would be impossible to prove one way or another. It might be more efficient, it might not-- it's definitely not guaranteed.

Changes for the sake of change is simply a bad idea. This is really just suggesting a different way to skin a cat. There would probably be little actual benefit from any of these changes.