You're right. I noticed that some networks do have it disabled, but there is still a high possibility of overlap. My example of an overlap in "+" is even more problematic, since a + user mode prefix is much more common than & anyway, and that scenario exists.
But in any case, hotlinking within the same network isn't even the only potentially confusing issue. More confusing is the fact that mIRC would have different hotlinking semantics across networks for features that most users are not aware of. A user on rizon and efnet would see &text hotlinked as a channel on one network and as a nickname on another. I think this would confuse users who don't know about & as a chantype, as well as those who are on many channels on both networks and don't necessarily consider the network of a channel they are currently looking at. Going back to our real example, +text would do the same thing across networks. I don't think *any* user would expect +text to hotlink as a channel. I think the UI should follow the element of least surprise here, and frankly, there are some prefixes that I don't think should ever be hotlinked as a channel for that reason. +text is certainly one of them. I'd argue that &text is probably uncommon enough to be opt-in via script as well, especially since, as you pointed out, it's disabled on at least a few large networks (rizon seems to disable it as well).
