I'm not talking about "refining the interface", nor "an overhaul", I'm talking about building an interface that works for the game we already have, and making each new chunk of code have an interface that actually works when it comes into the game.
Working on the interface constantly and in small, iterative steps is the only practical way to handle the game.
If we are the alpha testers of this game, we need to have access to the information that is being passed around in the game to know when things are going wrong. (Or are we to believe that we are not in an alpha, and we are to treat everything in the game as though it is a finished product?)
Further, if you step away from the false dichotomy choices of "the only alternative to doing everything now is doing nothing now", you can easily see many things that need to be done for the long-term for the game that would be of great benefit, now, and could be kept without scrapping later.
Cursor memory, implementing basic scripting commands like the Standing Orders suggestion (which was the top ranked eternal suggestion, along with many other interface tweaks in the top ten like automining veins), putting in simple keypress links between information-gathering modes, working on ways to put information on the same page as the decision pages, and developing the automation and autonomy of the actions of the dwarves in general.
That last part, especially, will never be completed in a single thrust, and understanding the quirks of how it is (and will be) built will have a dramatic impact upon how the game is designed going forward.
You can paper a GUI over all the bare gears in the engine later in some big "overhaul" if you want, but the basic mechanics for the interface need work now, and when you've done a proper skeletal interface, you can actually have a much better grip on not only how the game works, but on how the player will eventually approach the game.
Don't lie to yourself - the way that you see the game now significantly colors the way you actually think about or do things. Playing the game by Stonesense means caring about things far different from things you care about when you play the game normally.
I'm probably one of the very, very few players who actually builds multiple vertical shafts to compact my fortress vertically, rather than spreading out the fortress in a bunch of huge, clunky rectangle rooms specifically because players only view one floor at a time, and the digging tool favors rectangles. Central staircase designs are a direct artifact of the current interface.
If you change that interface, you change the way that players approach the game. How? You'll have no idea until after you do it.
We rely almost entirely upon hacks and micromanaged tweaks to make the game work in its current state - if we are ever going to get a game that works properly, Toady needs to start work on understanding how the player should be controlling their dwarves... And right now, Toady really doesn't have an earthly clue. He can't even give a committal answer on how much autonomy or direct control players even should have over dwarves in general.
In fact, the longer Toady puts off understanding how to build an interface, the worse it will be for him to fix many of its problems, for much the same reason that putting off fixing bugs and building more systems on top of the bugs only makes the bugs far more difficult to fix.
Besides which, by these measures, why should Toady be implementing goblins and sieges into the game now when he's just going to change how sieges work in the future? Or do you like having them in there to be able to enjoy playing the game?
What about raws? Rawifying everything will take a long time, but the more Toady works on making sure that all his new things are in the raws, the easier the eventual rawification of the game will go, because so much of the rest of the game is already prepared for being transitioned.
It's a bizarre double standard to say that we should encourage Toady to make complex systems, but asking that we actually be able to see and interact with those systems is somehow too much of a burden upon him.
The case of the eyelashes is an especially egregious case of a fetishism for simulation without practical interface - if nothing in the game interacts with that mechanic, if the player can never see it, if you can't even notice whether that mechanic is even there or not, why, exactly, is it there, eating up memory and processor time every single tick counting down to the next time when the hair will grow another millimeter? (And it was bugged, and nobody ever even knew it until memory hacks revealed it over a year after it was coded in! Toady never even bothered testing or figuring out a way for anyone else to test it.)
This is the perfect case example of what not thinking about the interface will produce - a perfectly useless mechanic that merely exists to eat processor time. That's why thinking about the interface at every step along the way is the only practical way to code a game.