I don't see the problem; * and ? are also significant if providing user input to iswm. You would have to escape all three characters either way, the extra matching of <string>& isn't going to change much. Also it's not significant "everywhere", only in the case where it is followed by a space or EOL-- but I'm sure that wasn't your point.
Flagrant is kind of an exaggeration here. "One" doesn't imply "whole", it implies one. "&" certainly matches one word, but so does "a&". There is also no rule that "&" must be delimited by a space, it is only used this way in a single example. Examples are not rules. If you really want to have a semantic discussion about the documentation's intent based on English vernacular, we can also discuss the fact that "&" will match a space delimited string "!!!", which technically isn't a "word".
But more practically, "sensibility" is less important than "usefulness". "a&" is useful in at least a few cases, and useless in zero cases, so there's no reason to get rid of it. Someone who is using "&" to match a "whole" word will never run into the problem with & matching a partial word, so it's not a matter of incompatibility. The only issue that would matter is the "user input" scenario, but as I pointed out at the beginning, it's no less a problem than "?", "*" or a regular use of "&" (which actually occurs far more often than "&" suffixing a word), so it's not specific to &. If it will make you happy, Khaled could update the description somewhere, but given that
versions.txt is not really a specification of current behaviour, I'm not really sure why it even matters. A mention of these wildcard matching characters in the
help file would be of more use, as well as a proper description of their functionality.
