LAZY_PREFILTER_MAP
If we wait until all tokens and arguments of a potential method send have been parsed before checking that all the arguments have the right types and precedence then we may spend a lot of extra effort parsing unnecessary expressions. For example, the "×" operation might not allow a "+" call for its left or right arguments, so parsing "1+2×…" as "(1+2)×…" is wasted effort.
This is especially expensive for operations with many arguments that could otherwise be culled by the shapes and types of early arguments, such as for "«_‡++»", which forbids arguments being invocations of the same message, keeping a call with many arguments flat. I haven't worked out the complete recurrence relations for this, but it's probably exponential (it certainly grows much faster than linearly without this optimization).
To accomplish this culling we have to filter out any inconsistent message bundles as we parse. Since we already do this in general while parsing expressions, all that remains is to check right after an argument has been parsed (or replayed due to memoization). The check for now is simple and doesn't consider argument types, simply excluding methods based on the grammatical restrictions.
When a message bundle's next instruction is ParsingOperation.CHECK_ARGUMENT (which must be all or nothing within a message bundle tree), this lazy prefilter map is populated. It maps from interesting message bundles that might occur as an argument to an appropriately reduced message bundle tree (i.e., a message bundle tree containing precisely those method bundles that allow that argument. The only keys that occur are ones for which at least one restriction exists in at least one of the still possible message bundles. When UNCLASSIFIED is empty, all such restricted argument message bundles occur in this map. Note that some of the resulting message bundle trees may be completely empty. Also note that some of the trees may be shared, so be careful to discard them rather than maintaining them when new method bundles or grammatical restrictions are added.
When an argument is a message that is not restricted for any of the message bundles in this message bundle tree (i.e., it does not occur as a key in this map), then the sole entry in LAZY_INCOMPLETE is used. The key is always the checkArgument instruction that all message bundles in this message bundle tree must have.