There's nothing "interesting" about it. That's just silly. The correct way to get any string with xyz123 anywhere in it is to use the wildcards. So you've killed off the possibility of getting an exact match (easily, at any rate) in favor of not letting people use the well established wildcards in a properly formulated search? That makes no sense at all.
If you want to find everything with xyz123 in it it's simple - just enter [star]xyz123[star]. It's not hard to tell people that, it's already documented in thousands of places and has been around for over 30 years. You have to use wildcards anyway if you don't want a totally crippled search utility, so using them to get [star]xyz123[star] isn't any greater learning burden than understanding that you use them to get, say, all .bat files by entering [star].bat.
Had to change the wildcard symbol from an asterisk to [star] because your editor apparently uses the asterisk to delimit italics - which is also weird. I can't say as I've ever seen that before.
So basically you are NOT using DOS expressions. So please stop telling people that you are (when not using "regular" perl expressions).
FileLocator Pro is ALSO not using DOS expressions if you have to delimit a string in anyway in order to get an exact match.
Regardless, I am apparently misapprehending your statement:
"If no extension is specified in the file name, e.g. xyz123.txt, then Agent Ransack will effectively search for xyz123."
This is not the behavior I am seeing so I presume that this isn't actually what you mean. Because the behavior I am seeing is NOT that searching for xyz123 (with no extension) returns xyz123 in a search, but in fact it returns ANYTHING that contains xyz123 anywhere in the file name, including:
So what Agent Ransack is EFFECTIVELY searching for is [star]xyz123[star]
This is a weird drawback to both versions that I simply do not understand, but I'll bet it's well-established in this product line now, so I figure the chances of getting searches implemented correctly is 0%.
It does mean that there is now absolutely 0% chance of me "upgrading" to the Pro, since it won't give me an exact match either via normal file search protocol, nor will I recommend it to anyone else.
You COULD fix this - just give us a switch at runtime to enforce true DOS expressions or not. Default would have to be not using true DOS expressions, since that's what you've trained your customer base to expect at this point, but setting a flag at runtime would at least allow folks to easily get an exact match the normal way, while not removing any capability at all. All DOS file search syntax would still work as-is, with the exception that now wildcard presence or absence would be interpreted correctly.