If too much of it is choice-adventure-specific that it can't be organized in any other way, then maybe it's not worth changing. It's hard to drum up excitement for a re-write when your collaborators don't see it as being a radical enough change to justify the cost/risk. I'm not sure anyone else has been convinced that can't is necessarily true, but we could be wrong.
We have a clunky solution that has grown over years into a very large clunky solution. It could use a re-write, although as Frono points out it isn't sitting at the top of anyone's ToDo list. But that's how open-source works; what gets worked on is what is interesting to the contributors, so that's not the barrier.
If you (or collectively, we) come up with an elegant solution, it could be easy to convince the dev team to make a change. If it looks like it will just leave the same problem for later, it's a harder sell. And between two equal solutions, the tiebreaker is going to go to the fielded code, since it has so many more hours of runtime testing. Better the devil we know.
tl;dr-- please consider what the threshold for accepting the changes are, and address suggested improvements as ways of helping you overcome them.
This is the very downside I was preoccupied with regarding the "split big changes into small steps" approaches: the individual step's values are scrutinized without the knowledge of how they help/fit into a broader change.
This rework is just meant to be a start.
The goal is to end up being able to log which choice takes a turn/increments the turn counter in a zone, which zone they occur in, have clearer/dynamic information as the choice adventure spoilers...
The issue is that this information often gets modified by some other context (for the spoilers), and not all choices cost a turn for a some choice adventure.
Storing handling by choice adventure allows one to see how a choice adventure's information gets altered over the various methods, which is why it is the first step.