I think you've hit the nail on the head.
It's basic economics. We should work to maximize marginal utility per unit input cost, or bang for the buck. Once a project is half completed, you've got half as much work to do to collect on the value of the project. Nowhere in the analysis do I see any cognizance of the cost of completion, and actually delivering the goods.
The sunk cost issue is a red herring distracting you from your actual error.
Just to be thorough, one should not forget about future discounting. Therefore, a project that is half-finished might be worth more than a newly discovered project that would take the same total amount of time and produce slightly more than double the payout, on account of the first project finishing earlier and earning interest.
I have a problem with never finishing things that I want to work on. I get enthusiastic about them for a while, but then find something else to work on. This problem seems to be powered partially by my sunk costs fallacy hooks.
When faced with the choice of finishing my current project or starting this shiny new project, my sunk costs hook activates and says "evaluate future expected utility and ignore sunk costs". The new project looks very shiny compared to the old project, enough that it looks like a better thing to work on than the rest of the current project. The trouble is that this always seems to be the case. It seems weird that the awesomeness of my project ideas would have exponential growth over time, so there must be something else here.
The "evaluate future expected utility and ignore sunk costs" heuristic works well for life-planning where people get status quo bias and financial-utility things where utility is easy to calculate consistently. In fact it seems like generally good decision theory, except that I'm running on corrupted hardware. My corrupted hardware seems to decay the perceived value of a project over the time that I know of it, or inflate it when it seems new and exciting, which of course throws off the sunk costs hook's assumption that I can evaluate utility *consistently*.
So my sunk costs hook has a bad assumption. I don't want to go modifying the hook in a way that would break its applicability to economic and life-planning situations or its theoretical correctness, so I'll just add "this assumes consistent utility function". This of course doesn't actually help me on the project planning case, I need to put a hook on evaluating the utility of a project that makes the utility function consistent.
Some things that might de-skew my evaluation of exciting new projects:
So I'll see how this works out.
I think this situation is probably not unique. Many of our debiasing hooks are formulated to combat specific biases but might catch situations outside their domain. In this example, the sunk costs bias is a real thing, but the hook to catch it was also catching a situation where sunk costs was not the primary bias, and actually ended up contributing to bias.
It might be valuable to think about what other situations a hook might catch, and modify it to not screw things up before we install it. Also, other biases may act in the opposite direction, and only hooking one of them might make things worse.
Anyways, that's my thoughts on a specific bit of debiasing. Maybe you all have some other examples of this sort of thing, and maybe this will be useful for people who have the same problem.