But we're not arguing the existence of "&" here. Whether a user does or doesn't know about & is irrelevant to the issue you're raising regarding the suffix syntax; it would still need to be escaped. To be clear, your problem is with the specific scenario of "a&" matching behaviour, not the existence of "&", right?
Following up your example with filenames, you often see song titles "Jon & James", but I've never seen "Jon& James"-- the latter might exist, but the former is equally problematic. So as I said, if a user wanted to match files they'd have to know about & and escape it regardless of whether it matched a "whole" word or a "partial" word.
I guess the real question here is whether you have a problem with the behaviour or just have a problem with the way it was described? This wasn't clear in your initial post, as you just listed the "contradiction" but didn't say which one you considered "right". I'm all for having the wildcard syntax actually documented in the help file, if that's all you're really suggesting, but I don't see how the current behaviour should be considered a bug.
PS. My point about sensibility is that reading too much into the
versions.txt file is irrelevant-- it's not a specification of current behaviour, it's merely an approximation of it. Even the help file isn't always considered specification when it comes to mIRC (the age old help file inaccuracy problems).
