One thing that strikes me is how this is similar to how a factory operates. While the existing tooling certainly is used for mass production, it is also regularly retooled for new requirements. These might be small changes, involving only a few minor molds or stages, or very large ones, involving complete replacement of whole sections. These operations also face the shifting sands of obsolescence and modernization, as well as changing market requirements.
It seems reasonable that all the expenditure to create the current tooling of the manufacturing plant is a capital expenditure, even tho, like software, it is never "Done", but rather in a constant state of progress and development. All of these iterative changes are likewise much akin to a form of research, albeit incredibly practical and occuring right where the rubber meets the road.
The modern picture of software development and operations you very clearly layout makes this capex framing more imperative and reasonable than before, despite not producing "done" assets. While it's certainly true that installation costs, bug fixing, and testing during production are not easily seen as capital expenses, it sounds reasonable that the other work to produce these production assets really is capex.
It also seems as if the IRS guidance already specifies this distinction, with the former category being specifically excluded from the proposed rule changes. Thank you for this very engaging and informative discussion! :)
A major source of short-term-ism in software value is the blurring or outright erasure of the boundary between development and operations, and the reality that more software is architected under these assumptions. Unlike features, operations is a constantly moving target, and it can reach pretty deeply into your software stack.
Anecdotally, for the types of software I work on, probably half of the development work exists to satisfy an operations rather than product feature need. These are often chasing exogenous metrics like improving opex. A lot of this work becomes irrelevant or dead code in much less than five years as the sands shift or we need to do things differently.
I am old enough to remember when software components almost always reached a state of “done”. That is rarely the case anymore. Testing has massively improved since then so the threshold above which companies will replace working code has been greatly reduced since the risk of doing so is much lower. We do forklift upgrades now that would have been unthinkable 20 years ago because of how thorough modern testing and tooling is.