Hm, however, isn't it customary with any programming language that invalid input shall never return valid output? For instance, $left(abc,0) returns null, not "a". So why should $mid(abc,0,1) return "a", and not null?
Not the best example. 0 isn't exactly invalid there. You're just saying to display 0 characters from the left. That's what it's doing by being $null, so $null is a valid output rather than an invalid one. That being said, I do think $mid() should probably display $null (as a valid output, not because 0 is invalid). That would let you loop through from positive to negative in a more accurate way if you needed to... $mid(string,-1,1) = g, $mid(string,0,1) = $null, $mid(string,1,1) = s.
As far as #6, I think that's also by design. It ignores 1-2 additional sequential command characters (including . and treating // as a single character) that appear before the command name if provided. Although I'm sure it's by design, I don't think it is really all that necessary. Especially if it doesn't treat alternate command characters the same way. So although I think it's by design, I do think it would be better to not ignore additional characters.
And, as mentioned above, 3 and 4 appear to be by design as well. I'm sure /say could support . without a problem, so that could probably be added. Though I personally stick to /msg instead of /say for scripting. And when the first character in a line is Ctrl-O, it's basically the same as not having that character there. mIRC's just ignoring an unnecessary character. I can see potential reasons for wanting that character to appear, but in almost all situations, the character is not needed. But to support the rare cases where it might be needed and because it wouldn't hurt anything, I think including it would be a good option.
