Right, so Raccoon pointed out that actually this bug report is a bit invalid. My tests weren't correct, the '-' was not part of the nickname (I was hovering -nickname- from a displayed notice using mIRC default display), and the nickname with `, let's say X`, was not connected, but X was, and that's why mIRC reports that as the match.
So to conclude, what's really problematic now is that if you have X and [X] on a channel and you get both these words to trigger on hotlink, both $hotlink(match) will report X as the nickname, which I find incorrect but is still explained by what Khaled said.
Now why is that a problem (to me)? Well, because we would be happy to be able to hover <@nick> and be able to get 'nick' from it, easily, without doing string manipulation ourselves, which is what I thought was possible, but in fact it's much worse; $hotlink(match).type being 'nick' does not guarantee that you hovered a nickname in a channel, you actually have to do string manipulation on $hotlink(word) by yourself to remove all the character not valid in a nickname and then check that the nickname is on the channel. To me this makes $hotlink(match).type for nickname not so useful, to say the least.
