$address(nick,N) has been defined for N=0-9, then repeated for N=10-19 as the same 10 strings except for numbers in the @host being replaced by "?". The 4-of-10 masks which use "*user" are handling it differently than every server I've seen handling it - which affects cases where there's a 10-character userid without the ~ tilde, and where there's a 9-character userid with the ~.

The difference is that mIRC behaves as if servers swap the 1st character of a 10-character host to make room for the ~ that indicates identd failed. However servers are actually dropping the 10th character to make room for the tilde.

For example, assume someone has the 10-character identd user string ABCDEFGHIJ, and has $address(nick,5) being nick!ABCDEFGHIJ@firstword.example.com

mIRC returns $address(nick,3) as *!*BCDEFGHIJ@*.example.com

However, if their identd fails the next time they connect to that server, their userid drops the last letter J and becomes ~ABCDEFGHI, causing their mask-3 string to now be *!*ABCDEFGHI@*.example.com

This creates a pair of mask-3 strings, neither of which matches that same user in both conditions of ident-enabled and identd-disabled.

In summary, in creating "*user" masks, mIRC replace the first letter with an asterisk, regardless whether or not that character was a tilde. But mIRC also creates the "*user" without allowing for the cases where adding the leading tilde forces a tenth character out of the userid. The server's handling method creates a problem when there's a 9-character userid preceded by a tilde, as there's no way to know if a 10th character would appear when the tilde goes away.

Any solution should not involve changing how masks 1/3/6/8 interpret "*user" for userids longer than 8 characters, as that would break handling for those masks in many scripts.

One solution could be, that since masks 0-19 have been defined, additional masks could be created to have altered handling of "*user". Current interpretation of '*user' in all masks is to replace the first digit of the userid, regardless whether nor not it's a tilde.

The new masks could begin with the asterisk, but remove any beginning tilde as they include the first 9 non-tilde characters, and only add an ending asterisk if there were at least 9 non-tilde characters. This creates masks that work both when everyone has identd as well as when they lose it.

Another change that could be made is to add some text to the options menu where the identd string is entered, notifying people how it's not a good idea to put a tenth character in the identd editbox. Probably less assertive than the warning when setting 'on send request' to 'auto'.