Most probably the issue was ban masks. Many server implementations limit the username part of ban masks to the username length. For example: if you attempt to ban *!*1234567890@* on a server with USERLEN=10, the ircd may set the ban *!*123456789@* instead. This is why it is essential to keep enforcing the correct limit, and instead ban *!*234567890@* on such networks. That affects the way $mask (etc) work, and requires knowledge of the ircd's USERLEN setting. Unfortunately, it does not seem that USERLEN is generally reported as part of RPL_ISUPPORT..
That makes sense. Commands to the server for e.g. bans should conform to the specs. But there are several use cases:
1. Ban '*!123456789@*' - conformant should be no problems.
2. Ban '*!*123456789@*' - still conformant should be no problems.
3. Ban '*!1234567890@*' - not sure whether this is conformant or will cause problems - change to ban '*!*234567890@*'.
4. Ban '*!*1234567890@*' - non-conformant - change to ban '*!*234567890@*'.
In fact, this should apply consistently to all commands sent to the server which include a mask.
In other words, the issue is not with how we handle this at the client, but how we send commands to the server.
For the real-life example 'dragnbreaker!dragnbreake@*' we would use 'dragnbreaker!*agnbreake@*' which is what $address(dragnbreaker,6) produces.
So, $address(nick,6) is probably ok. Just $address(nick,5 / 15?) which needs fixing.
