All games have an inventory limit. (You probably don't like that either.) The implicit TAKE prior to DRINK causes all sorts of inventory management issues. If your inventory is full prior to DRINK COFFEE, do you:
- Tell the player they can't carry any more (and cause them some confusion because they weren't trying to pick something up).
- Allow them to exceed the inventory limit in order to carry out the action (and possibly break future inventory limit checking in the process).
- Drop a random object in order to allow them to pick up the coffee (and break the precious Ming vase in the process).
- Allow them to drink the coffee and put down the empty cup so as not to exceed the inventory limit (but do they put down the empty cup when they were already carrying the coffee).
There are all sorts of other scenarios, but this gives you a small sample of some of the problems involved when you allow implicit actions. This all requires a hell of a lot of extra coding that is not needed when you don't allow implicit actions and is far less confusing to the player in the long run.
Inform has the concept of a "sack" object. (This idea is taken from Zork.) If you try to pick something up when your inventory is full and you are carrying the sack object and it is not full, then it picks an item at random and puts it in the sack, then picks up the coffee so that you can drink it.
I remember a game where you couldn't pick up the coffee because it was too hot. What do you do then?
In my last game (a future entry in IFComp 2020), I wanted the player to be able to PUT WATER IN BUCKET. The library would not allow anything to be put in a container unless it was held first, so it would implicitly try to get the water (this is similar to your implicitly getting the coffee), but you can't get the water. That's why you need the bucket in the first place. So it was impossible to put the water in the bucket without modifying the standard grammar.
Do you see what I mean yet?
My point is that you have to be consistent. If you're going to allow an implicit action in one particular scenario, then you have to allow it in all sensible scenarios. This leads to a hell of a lot of extra coding and possible confusion to the player. In every game that I've ever played that allows implicit actions, I've actually ended up taking more moves than had there not been any implicit actions. This is because I am very thorough when playing a game in order to write up the solution for CASA.
In the old days of two-word input, the indirect object was always implied. This was unavoidable because of the limitations of a two-word parser. But implicit actions are quite different to implicit objects. Think it through carefully before you decide to go the implicit actions route.