An interesting semantic distinction.
I have always thought of [any …] tokens as overriding the usual requirements of scope implicit in constructing any action from a command, but I see how understanding ‘Understand tokens’ as the policemen of scope makes more sense, philosophically and in how the parser and action-processing actually operate. So in this paradigm:
Action definitions:
(i) restrict whether one or two objects and/or values can be used in the construction of an action
-these restrictions apply whether the action is constructed from a command, e.g. ‘Take the banana’ or in code, e.g. ‘try taking the banana’
-any action to be generated from a typed command or in code must match this basic definition or be rejected by the parser or compiler respectively
(ii) may add certain other requirements which are tested after the action is constructed and action-processing is already underway
-i.e. touchability/carriage of objects and/or the presence of light- specifically after the Before stage has had opportunity to intervene (by, for example, trying an ‘implicit take’ for an object which must be carried.)
Between the operation of stages (i) and (ii) defined in the action definition, in the case of actions generated from typed commands, Understand tokens:
(a) may restrict further what kinds of objects or values can be referred to in the command in order for it to be successfully translated to an action
- e.g. [someone] means that an object referred to in the action definition as a ‘visible thing’ must in fact, in a typed command, be a person
(b) enforce scoping rules, such that in the absence of the preceding word or prefix ‘any’, only objects that are ‘in scope’ can be referred to in a typed command in order to to construct an action
-N.B. scope does not apply to values, so for example [number] does not require ‘any’ to precede it (although [any number] does compile)
Naturally, as suggested above ‘Understand tokens’ are only used in parsing typed commands, not when code generates actions as in ‘try taking the banana’. Consequently, scope plays no part in code-generated actions, which can ignore all usual considerations of scope.
Similarly, code can generate actions including objects that no ‘Understand’ line would allow. For example, if you have 'Understand “Insult [someone] as insulting” as the only typed command-based syntax for the insulting action, code can still say ‘try insulting the banana’, which will not only compile but will also generate and run the action to insult the banana, ignoring restrictions of both scope and person.
However, restrictions to do with touchability, carriage and requirement for light appearing in an action definition will still kick in after the Before stage of any code-generated action. So if the action definition of insulting is ‘Insulting is an action applying to one touchable thing’, ‘try insulting the banana’ will only work if the banana can be touched, (barring any intervention at the Before stage to make it touchable).