API: behavior of rec-string on an ambiguous string

[ebblake]

The standard is clear that S\" \xQ" (and various other malformed \ escapes) is ambiguous behavior, even though there is no reserved throw code for it. But if rec-string is going to be standardized, we should consider documenting whether passing the lexeme "\xQ" must return 0 (there is no valid string recognized; let other recognizers later in the stack take a shot at the lexeme), or if it may return scan-translate-string (or some variant thereof) merely because the leading " was recognized, only to later have the resulting scan-translate-string fail with ambiguous behavior.

More generally, if any recognizer ever returns success, is that a guarantee that there should not be ambiguous behavior resulting from the later execution of that translation token? For comparison, if rec-to tries to recognize ->name as sugar for TO name, is it the recognizer's job to ensure that name is likewise recognized by rec-nt before rec-to can return success, so as to avoid the ambiguous behavior of trying to invoke TO on an unknown word? How far does this extend? If the implementation can reliably -32 throw on an attempt to use TO on a word that was recognized by rec-nt but was not created by a defining word that imbues TO semantics, should rec-to return success (only for the later translation to fail), or return 0 (to allow another recognizer later in the stack a chance to give an alternative meaning to that lexeme)?