I'll try not to waffle one too much about this, and I know already I'm going to digress from your actual question, but it might be interesting for some one, so... time to indulge a little bit.
I'm in a bit of funny position, because I never played Zork. I have heard about it and poked at it a little bit. And I did play "Softporn" on the old Apple II, but I tended to fall in the RPG (Wizardry, Might and Magic, etc) and arcade camp. Later, on consoles, I stuck with RPG type games, including the Zelda series, etc.
What I learned from that is that you can have a full, rich experience with a small set of "verbs", as long as the verbs can be creatively used and (perhaps even) combined, where the player feels that sense of agency - can the player solve the problems to be solved in a way that feels unique to the player, where the player feels like "I came up with that solution"?
Flash forward to my rediscovery of text adventures (now branded and expanded as "interactive fiction"), and with Quest, I began trying to write parser games. Two things have put me off them. The first is, ironically, that I have been reading the intfic forums. And I came to realize that what separates a good parser game from a poor or average one is the extent to which is preserves the illusion that "the player can type anything". That is a huge point that novice IF game authors often miss, and I didn't even know it myself. What it means is that you not only need to code what *you* would type in, but you also need to anticipate and account for all the other possible things *everyone else* might type in. And the direction modern parser-game design is going is that the game doesn't have to necessarily allow all sorts of things to happen, but it should be able to respond well enough to things to guide the player to what they need to do.
I have played games here on the Quest site that fall into the "there's only one way to get through this game" syndrome, even to the point of creating their own conventions that make on occasion make absolutely no sense (at least from my point of view). And yet people were able to play them because they somehow "got" what the author was doing and didn't care that they had to type nonsense at times to progress.
So that is my first stumbling block. A parser-based game must preserve that illusion of "you can type in anything", and people will often try typing all sorts of things into games to see how they respond, hoping to find fun things. It's a massive, major job, and I eventually found that I didn't care enough to actually make that happen. There are people out there who do, and they make amazing, incredible, wonderful jobs of it. I will never be one of those (unless I had some really strong motivation). There is a counterpart to that as well, which is that - having cut my teeth on RPG-type games and point-and-click and arcade games with more limited controls - I just don't have the patience to try to figure out the magic incantation I have to type in to get things to work. I'm too old now, and life is too short to spend a lot of time going down dead ends that I don't know are dead ends.
My second stumbling block with parser-based games is what happened when I was first working on spondre, when I handed the beginnings of my game to my wife. I had the same experience you did - she fumbled with it, tried typing all sorts of things in, and got generally frustrated. Now, there has been a lot of discussion in the IF forums about what to do about this - how do you train the player in the IF conventions? It's not trivial, and it's not easy. But it seems essential, to perhaps have some sort of up-front tutorial mode as you see with other, non-text games, for those who haven't played before. Or if not up-front, then more implicit, as-you-play sort of help, where the game sees you're having trouble and helps out.
That is no small task.
So I had two problems: first, making a good parser game is hard, and second, playing a parser game is hard. And I want to write games that I can give to my wife, my kids, my parents, random people on the internet, and have them all at least be able to know what to do.
On the other side, you have CYOA (gamebook) type games, where you read some text and then pick from options. That has the same sort of problems as you mentioned above, where everything is up front, and you're picking things rather than entering commands of your own devising. I've played games like that, some even highly regarded, and I lose interest. I tend to focus on the choices instead of the text, and the choices often have nothing to do with me or what I want. I was playing "80 days", for example, and part way through, I realized that I was making choices fairly automatically, I didn't know why I was making them, and I just didn't *care". And I gave up. The game has a fantastic interface, with things I'd like to emulate, but after choosing different paths and whether to go to the bank or spend the night or buy supplies or... They weren't choices that mattered to me.
So you have on the one hand a parser interface that gives the illusion of "you can type anything" (which, as Emily Short rightly pointed out, is a lie, and knowing it's a lie makes it hard for me), and on the other you have a game where the game offers you what to choose.
There is also another variant, which has inline links. It could be called a "hypertext" game, and I think it has promise, but it tends to have a similar feel to me to the CYOA one, if done poorly. Nothing bothers me more than having text with (say) three links, and when I click a link, the text and my unselected choices go away. That leaves me with the same feel as a CYOA, where I have to make a choice without necessarily knowing what I'm choosing, and then I'm committed to that choice.
What they lack is the ability to *explore* a game. That is changing in some ways, in that game authors (Twine, etc) are more now having recurring paths, where you can go back and revisit earlier choices, but you still get whisked away without knowing when it will happen to new places. It has an "out of control" sort of feel to me.
Quest's verb pop-ups are a sort of hybrid. You have the parser input, but you also can click on objects and get verbs. It's a mix of two interfaces, and they conflict to some extent. You can use the verb menus to try to compensate for the parser, but it won't teach people how to use the parser, and you can't put everything in the menus. So you end up training the player to interact with the game in a way that is ultimately incomplete and won't get them to the end. I think if I was going to create a parser game, I'd just create a parser game. If I wanted to use links, then I'd use links. If you have a game with both, then you should be able to do anything in both, but then you have two interfaces. Why? (One reason I got rid of the command prompt in spondre is that Pertex asked me why I was bothering with both modes of input, as I had clickable links as well. It was a pertinent and revealing question for me.)
Now, you can justify the pane as a place to look to see things like inventory, so you don't have to try to remember or have to keep polluting the game output with "i" commands. You can also, perhaps, justify clicking on the panes if you look at them only as extensions to the parser. That's basically what they are - extension, not replacement. But they can never solve "the parser problem". They can only be used as shortcuts if people want to pick up the mouse.
For me, I'm still looking for the ideal interface. It won't be parser for me, and it won't be CYOA. I think it will be some sort of hyperlink thing, but the hyperlinks bother me (they distract from the text). spondre had links but they didn't show, which might have worked if I had done it right, but that might be doomed as well.
Ok, that was long and perhaps touched on things that had nothing to do with your question. But I think I at least arrived somewhere close to your question, so I hope it's useful.
