I think what Hanami had to bring to the table is already on the table for years - slice architecture, repository pattern, true view layer, explicit dependency management and perhaps one that it recent - first class operations support. This release indeed does not bring a lot in that matter, rather fills the gaps in the ecosystem and DX.
The phrase has been weaponized in the past many times. Some figures in the community are almost as far from "nice" as possible, but you're not allowed to call that out, because "it's not nice".
99% coverage does not mean you have good tests. Yes, I have experienced that good tests, combined with a good understanding which parts are critical and which are not, create a great comfort about introducing changes, whether it's Friday afternoon or Monday morning.
In my books the difference lies in how the HTML is generated. In case of static sites you generate it only when you rebuild the site after changes. In dynamic sites you build it dynamically on each request. Sure, you can cache the hell out of it and have a feeling that it's the same, but the truth stays that perhaps you're doing 50 SQL queries for a simple "welcome on our site" landing (something I actually witnessed some years ago). And with caching you're achieving the result with adding another infrastructure layer on something that could have been dead-simple from day one.
Ruby is super backwards-compatible with new versions. Even to much. The core team almost made religion from it. So I don't really understand what the problem is - aside from using not maintained library. It will work, unless it was written for 1.8 or something.
Ok, that is good to know. However from my mere-user perspective it does not look so good. With Hanami 1.3 release it was announced that Hanami 1.x line won't get anything past bugfixes and security fixes, so it basically won't be developed. Instead, the work shifts to Hanami 2.0, which will include considerable number of completely breaking changes (such as different signature of actions call method). This goes on for almost 2 years now, with no clear timeline for 2.0 release. Is there a point in starting new project in Hanami 1.3 and having to completely rewrite it when 2.0 comes out? Probably not. Does it make sense to used very early-stage 2.0? Definitely not. So yeah, from my perspective the project is now in a problematic state.
How is it "around the corner"? While having been enthusiastic about Hanami since Lotus times, I cannot help the feeling that it's more or less completely stalled at the moment. Sure, the non-functional alpha of Hanami 2.0 has been released some time ago, but nothing really happened since then (except from releasing hanami-api out of the blue). There is no timeline and Trello board seems to not be in line with state of PRs for Hanami 2.0.
Chapbook looks nice, but even after first glance I see a lot of things potentially missing, such as possibility to redirect to "death passage" from each passage if health drops below zero. Maybe it will be developed in that direction, but for now I feel Snowman should be a default choice for any developer trying out Twine, because you basically code everything in JS.