I think I’ve figured out a good default behaviour now. The problem with the old solution is that it first resolves the ambiguity to a standard action, and then potentially redirects that to another standard action, after loosing vital information about how the command was worded. That makes it difficult for the story author to override the default behaviour in a clean way.
It’s better to deal with the ambiguity at the parser level. The idea is that a direction like DOWN will always be understood as referring to [go #down], but sometimes also as [leave $]— namely if the player is on a supporter.
Since the command can be parsed in two ways, the likelihood of each interpretation is considered. If there is no exit down, then [go #down] is deemed unlikely, and disregarded. So the player can only be asked a disambiguating question on those rare occasions where e.g. the player is on a supporter and there is also an exit down, or inside a container when there is also an exit out. And here’s the kicker: The story author can easily resolve those ambiguities by tweaking the likelihood of actions, taking the full story-specific situation into account. Thus:
(unlikely [leave #balloon-animal])
(current room #air)
or:
(unlikely [leave #submarine #up])
(#player is #on #bunk)
Again, this only affects ambiguous cases. If the player on the balloon animal types GET OFF, or LEAVE ANIMAL, it doesn’t matter that the action is considered unlikely, because there is no other way to interpret it.