> In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Extra features like paperwork and features not often used by customers are waste. Switching people between tasks is waste (because of time spent, and often lost, by people involved in context-switching). Waiting for other activities, teams, processes is waste. Relearning requirements to complete work is waste. Defects and lower quality are waste. Managerial overhead not producing real value is waste.

Note what isn't included: Necessary but hidden things. In fact, one of the things included here is explicitly the opposite of what OP included - defects (bugs). They called fixing bugs a waste, while this is saying having bugs is a waste.

Everything I'm seeing from the responses I've gotten are just reinforcing that OP is wrong about this word, whether it be straight Japanese or altered English jargon originating from ７つのムダ.

“Defects: Having to discard or rework a product due to earlier defective work or components results in additional cost and delays.”

In TPS and Lean, you’re expected to build quality in. So, while fixing bugs is necessary, it’s considered a type of waste, to be eliminated by building software without bugs.