Ron Gilbert (Monkey Island, Thimbleweed Park, …) has a very good method of designing puzzles, which technically speaking is not enumerating the different puzzle types, but it’s a good general method of designing puzzle (and optionally narrative) flow - which is often more important than the quality of individual puzzles.
I personally design puzzles from the point of view of flow. Early puzzles should be relatively easy, the pre-game should give some quick wins, and certainly should not result in the player getting lost (gate off the rest of the game). After the pre-game, make sure there are at least 3 puzzles that can be worked on at the same time, then gate your progress through the “acts” of your game. Each act leads to multiple new puzzles that can be worked on.
Types of puzzles I like to use are observational puzzles (notice that a dog follows you for one turn after you pet it, notice state in one room changing in response to something you did in another room), transformation puzzles (identify something you might need somewhere then realise that you might need to combine items in the game to create that item), state puzzles (notice you need to change the state in a room in order to be able to get past a barrier), conversational puzzles (notice what an npc might want you to say to them in order to achieve a goal), mutual exclusion puzzles (solving one puzzle will remove the solution to another puzzle - how do you resolve it), groundhog day puzzles (give the player knowledge of future death, and then the player must mitigate the death as they approach it - note that sudden death mitigation must be in place for this), … and more.
Puzzles (in parser games) are intrinsically exclusionary. If there is a single puzzle that a player can’t solve, then they can’t make forward progress. It does help to have multiple things to do at the same time, but ultimately, you will always hit that bottleneck. It is essential to have a system in your game, or on your game page that rescues the lost player. It is also important that every solution should make sense in hindsight and does not evoke a reaction of “oh, that’s impossible, how was I supposed to know that?!”.
Other types of games have the ability to respond to poor player skill levels by covertly modifying difficulty levels, I think text adventure games really need the same sort of mechanism, but perhaps in the form of truly intelligent context-sensitive help.
I actually wrote a little-read article where I postulated that puzzle dependency charts, laced with hint metadata could be used to provide level 1, level 2, level 3 hints for every “puzzle”. The game would know what hint to provide by checking the currently open puzzles, and looking up hints per puzzle.
Choice based games may be simpler in that you may engineer a game to always result in an “outcome”, but the outcome may or may not be a “good ending”. I’d argue that a bad outcome in a choice based game is the same as sudden death - but that’s a tangent.
Enough of my rambling, here is the link to Ron’s blog, yet again: