Re. micro-optimization, there are actually arguments out there (I don't remember any of the details because I'm not wildly interested in optimization, I prefer to pick it up where code is already robust and there's an obvious inefficiency that can be corrected without altering the robustness; so take this with a grain of salt...) that most optimizations that go lower into the details than reworking the overall structure are the most likely thing to stop the compiler from optimizing even better than you can, hence that most programmer optimization actually makes the result worse. On the other hand, there are arguments that modularity is opposed to optimization since it's hard to optimize the details of functions that are neatly split up into pieces and spread across various components of the program. And, mind you, that's talking about optimizing human-readable code that the compiler has flexibility in turning into the optimal binary code that accomplishes what the human-readable code says to accomplish... There are people out there who still write libraries in assembler and boast of benchmarking them against the most lightweight and efficient C libraries and proving their assembler-based library is several times faster, but I don't really know how they get that good at that sort of programming -- they're probably the same people who can literally calculate hundreds of digits of pi in their heads and stuff like that.
That digression aside... Toady, you mention bug fixes and job priorities in discussion of future focus. When job priorities are revamped, will we have any level of control over changing those priorities, or will the priorities only be improved in weight and/or in the algorithms used? At risk of being suggestiony, I think right now simply letting us change the priority system's weights so things like cleaning don't have to always be apparently lower priority than idling would be sufficient to alleviate most of the complaints I've heard about the current priority system. Relatedly, "On Break" seems like a misnomer for "dwarf is dead to the world for the better part of the month, out of nowhere, entirely beyond the player's control and inevitably at the one time when you need that dwarf for something; until further notice act as though you will never see this dwarf again." Will breaks be revised in any way along with job priorities, either to make them more workable for the player or perhaps to increase their inherent benefits (or make there be some inherent benefits if there currently are none)?