But FILL wasn’t broken. It was PUT that was broken. If you change FILL to behave the same as PUT, then they’ll both be broken.
The PUT stuff in grammar.h is wrong?
No, it’s not the grammar, it’s the multiexcept token. If you use this token, the examples given in the original question never get to the before routine, so you can’t handle exceptions to the general case. The responses don’t make sense and are somewhat random for reasons I can’t fathom. Run the standalone program in the original question and you’ll see what I mean. The only workaround I could find was to replace the multiexcept token with noun and everything works fine.
My I6 is way too rusty, but I suspect that your issue with multiexcept and scenery objects is related to some trouble I had recently in I7 with the [things] grammar token completely ignoring scenery objects if it could find any matching non-scenery objects.
Does it work as expected if your water is not scenery or backdrop?
The workaround I ended up doing (again, I7, sorry, but you should be able to adapt it) was to make the object fixed in place instead of scenery and then use another rule to hide it from the location description instead. (This was the thread discussing it, if you’re curious.)
This is a bit off-topic, but the issue arose when the token could find exactly one matching non-scenery object; if it could find two then it didn’t arise. See this post.
(I also kind of doubt that this is the same issue, because the I7 issue seemed to have to do with some things in the I7 parser like the “deciding whether all includes” activity that I don’t think are in the I6 parser, but I really don’t know anything about I6 and can’t be definitive there.)
Thanks for the suggestion, but I’m pretty sure these are different issues. For me, reading Inform 7 is like reading a foreign language. I just don’t get it.
I don’t think my issue is related to scenery, as it occurs with scenery objects and non-scenery objects as shown in the example. It occurs because I’m using no_implicit_actions. I think everything works fine when not using that. I can’t use implicit actions because it causes various issues elsewhere and if I do use it, it tries to get the water first, the water trickles through your fingers (not shown in the example), so you can’t put it in the bucket. What I want is a transfer action. If I say PUT WATER IN BUCKET (a very natural thing to try), I should be able to run a before routine that allows me to do the transfer, but it never gets to the before routine. The library thinks it knows better and spits the dummy with nonsensical error messages.
It is in the I6 parser; it’s the ChooseObjects entry point (phase 2). But Warrigal looks correct in saying that that’s unrelated.