It's common nowadays to see people complaining online that there are too many games out there (or books, or music, you name it). It's not nearly as common to hear them complain about too many game development tools, but that's mostly because fewer people are game developers; if you hang around in the right circles, you're bound to come across that one sooner or later. Interactive fiction, in particular, seems to suffer from this; a big part of nurturing new authors is helping them pick an authoring system. Already in the 8-bit era multiple companies sold competing products, in addition to the proprietary tools of major studios. Nowadays, the Cloak of Darkness website alone compares no less than 20 of them, and that's just for parser-based works! As for me, I created as many (toy) authoring systems as I did text adventures — one of which actually saw real-world usage, to my eternal surprise and gratitude.
And there's absolutely nothing wrong with any of that.
With so many authoring systems out there, some of them come so close in features and overall feel as to seem redundant. That's inevitable. I will also argue this is a red herring. Funny, isn't it? You never hear anyone complaining that markers and highlighters are redundant. Or crayons and colored pencils. Tempera and gouache. You get the idea. Arguably, software is different because it tends to proliferate in a way physical media do not, due to programmer hubris and the nature of computers, and I can't fault people for feeling overwhelmed. But even subtle differences may matter more than you think.
In the rest of the article I'd like to compare three authoring systems for browser-based interactive fiction, with remarkably similar design, that nevertheless make for a far from trivial choice.
Launched in 2010, Undum was the first choice-based authoring system I remember making a big splash, not least due to its heavy focus on excellent typography out of the box. Having built-in support for features like save, restore and undo couldn't have hurt, either, and "qualities" makes it suitable out of the box for RPG-like experiences reminiscent of old gamebooks.
Not long after that, Alex Warren of Quest fame came up with Squiffy, yet another tool for making interactive fiction in the same style. Unlike the other two systems, Squiffy compiles games from a lightweight markup language, which includes shortcuts for things like counting how many times a passage has been read, that must be tracked manually in Ramus (not sure about Undum). Compiled games look very plain by default, but that's easy to correct with basic knowledge of CSS. Which is, of course, both good and bad news.
Now, at the core, all three systems produce mechanically identical works: interactive stories that unfold visibly as you make your choices, turning into a smooth linear narrative that reads like it was written that way, mainly by hiding the links not clicked (but leaving the previous text passages). That's a lot more similarity than between works made with Inform versus TADS, for example. One could easily argue we only need one of these systems. Undum was first, and still the most famous by far. It's gorgeous out of the box, and make no mistake, that matters. It has a lot of useful features on top of the core mechanic. So why would anyone bother making not one, but two other systems that do the exact same thing, more poorly?
That's all from an author's perspective, and as such it already influences what the audience sees. But even if you're strictly a reader, the differences are more than just aesthetic. For example, Squiffy lacks that fancy scroll-and-fade-in effect of the other two systems... but that makes it the only one well-suited for dedicated e-readers! It's also the most plain-looking by default... but it means you can bundle your game as an EPUB 3 file and let the e-reading software deal with typography. Funny how it all fits together, isn't it?
So yeah. Just as writing with a pencil versus ballpoint versus fountain pen yields distinct results, even though your vocabulary and paper are still the same, three authoring systems for the exact same flavor of interactive fiction can make for works that don't read the same and don't play the same, in ways no less real or meaningful than "parser disambiguation works differently". And it's worth putting some thought into it when creating a new authoring system, because authors will consider it, and that makes you, the programmer, partly responsible for the results.
(P.S. Raconteur can be found on GitHub.)