Consider the following scenarios that occur only because of the addition of Abbreviated Object Names (AON) in Quest 4.03:

If two objects have no alt names, but Object 1 has an alias of "screw" and Object 2 has an alias of "screwdriver", a disambiguation menu appears when "get screw" is typed because AON allows the "screwdriver" to be considered a "sc," "scr," "scre," "screw," etc.,... this is not good - a screw is a screw, not a screwdriver, and more disambiguation menus is a less than favorable outcome.

If two objects exist, in which Object 1 has an alt name of "screw," while Object 2 has an alias of "screwdriver" and "get screw" is typed by a player, the "screw" is picked up... (Ok, so far that's what is expected.). But while holding the "screw," if a player types in "get screw" again, then the "screwdriver" is picked up... (just plain confusing... the player already has the "screw," so how about telling a player they already have that?). Furthermore, if a player types in "get s," "get sc," "get scr," etc., while holding neither the "screw" nor "screwdriver", the "screwdriver" is picked up, but what if a player means to get the "screw"?

See, without knowing the rules of how AON functions, a player is just dropped into discombobulation without warning, and to assume a player will learn how AON works is just asking too much from them for a technique that will just dumb them down and whose functionality is rather useless. Also, from the perspective of testing code, it just makes it more difficult to discern why some unexpected errors are occurring.

I don't like this feature. If you find AON more of a hindrance than purposeful, please let Alex know. At least, I believe AON should be allowed to be turned off by an ASL programmer.