If this were the case, then any number would return the total number of user's with this usermode in the channel. It only does this if the "nickname" is 0 or a nick is 11 digits or more.
That statement holds little value and isn't quite correct...
A "nickname of 11 digits" is
not a nickname as defined by the IRC RFC (the protocol mIRC implements and follows), and therefore what you described simply does not exist in mIRC. It will just be a number.
So, knowing that you're dealing with a number (it's not a nickname), the mIRC documentation for $nick defines N as a number ranging from 0-N where N is the total number of users in the channel. An 11-digit number is therefore an invalid input to the identifier and has
undefined results. You can't really blame mIRC for reacting oddly to bad input.
This goes back to starbucks' point... mIRC will only parse the N as a nickname if it is not a number (or not one of reasonable length, as you noticed)... mIRC made this design decision because the IRC RFC defined nicknames as beginning with a letter. The language makes this assumption in too many places to count, and so you won't get much further than $nick before you run into another number-related nickname issue. But the bottom line is that none of these would be bugs, since $nick(#,N) was not intended to be used the way you're using it.
Keep in mind that even if you still think this 11-digit length limit is relevant, your script would still fail if there was a nick of "65" in, say, an 80 user channel, because $nick(#,65) = 65th user in the channel... so the issue isn't really to do with 11 digit numbers at all, it's much more deep-rooted than that, and again, is directly related to the IRCd completely breaking the IRC spec. I think we can agree that there's really nothing at all that mIRC could do in a case like the one I just described, so fixing it for 11+ digit "nicknames" would only solve one of the many other cases that you would otherwise consider "a bug"-- why bother?
