<pretentious mode>You're asking the wrong question</pretentious mode>
No Haven has a lot of text content. Such content could not easily be converted to another format (such as cutscenes with voiceover narration). Therefore we ought to choose an engine which can deliver a lot of text (and provide tools for text formatting, sizing, alignment, scrolling, etc).
No Haven uses text-based menus to present information to the player, and to solicit choices from the player. The information is important. The choices are important. The menus are not important. They exist in the current game because they were the most convenient option available under RAGS. If No Haven had been written on a different platform then we might be forced to choose missions via an even-worse mechanism (such as typing the mission name into a text parser). In such a case, we would not be asking ourselves "which game engine has the best support for text parsers?" Instead, we would be saying "I'm very grateful that we can finally abandon the text parser bullshit because we have access to superior forms of interaction."
Let's consider an example. Currently, my vote for the least-pleasant aspect of No Haven's UX would be armor/clothing. It's a tedious clickfest which (at any particular moment) hides much of the relevant information from the player. Let's say that I want to assign the best possible gear to my newest recruit, Bill the Ogre. The armor menu shows only the set of unassigned gear. I'll need to click through each slaver (via cumbersome menus), note what they're currently wearing, manually decide which item is best, unequip it from its current wearer, equip it to Bill, and then choose alternate gear and equip it onto the naked guy. The whole process might consume 60+ seconds of playtime.
Note: XCOM2 suffers from a similar problem. In the base game it's manageable because the game encourages the player to use a small elite team. Mods (ie Long War 2) force the player to manage a much larger roster, which means that the player must waste time navigating through the Loadout menus ( ... or just send your team into combat with sub-optimal gear because you can't be bothered to deal with the frustration).
Instead, let's imagine that we show a graphical team roster (e.g. grid of portraits or paper-doll silhouettes) wherein each character is accompanied by an icon showing their current gear. I can reassign equipment by drag-and-dropping it from one character portrait to another. Comparison can be done by hovering the mouse pointer over a particular piece of gear. The operation could be completed in a few seconds.
I don't mean to imply that the game should become entirely graphical. There are some cases wherein Datagrids would be appropriate (for ease of comparison and player-driven sorting). Right-click context menus should be retained in many places. The choices which appear during missions should probably follow Visual Novel convention, because that's a familiar UX for players.
DF has godawful menus. Everyone knows that they're godawful, although there's some denial due to Stockholm Syndrome. Expert players can navigate the menus quickly, but that's due to muscle memory rather than good design. Large forts become borderline-unplayable without Dwarf Therapist.
You must be registered to see the links
uses a Therapist-style grid to present labor information and solicit player choices. This was a good decision. Re-implementing DF's godawful menus would have been a mistake. The developer wisely asked "what's a good engine to deliver the intended gameplay experience?" instead of "which engine can faithfully recreate the original game (warts and all)?"My preference is Unity, but it's a very biased position (example: I have an irrational hatred for Python, and my experience with Unity leads to
You must be registered to see the links
). It's currently moot, because BedlamGames is proceeding with Twine. Until we can convince him to reconsider that choice, the "best" question is academic.
