[gfodor]

Eh, I think terminology can evolve. Technical debt can also mean incidental complexity explicitly and consciously being introduced at the code level for very good reasons. And paying down the debt means code-level refactoring, introducing abstractions, unifying interfaces etc. It can also mean throwing the code out since the experiment was a failure. (One thing often overlooked on incurring tech debt is there are cases where you can just 'write it off', when the thing you thought was going to be important turned out not to be, so you can just kill it.) The opposite of incurring technical debt can be over-engineering, for example.

Personally I find it an improvement to have two terms that separate the concepts, if for no other reason that it underscores that 'conceptual debt' is a thing that matters a lot and isn't just 'the engineers can come in and clean it up later' type of deal, which technical debt often can be. Recognizing conceptual debt as something that all team members can contribute to, not just people writing code, is a profoundly different type of conversation than the ones you'll have today around tech debt where it's assumed a) stakeholders can't understand it and b) it's nobody's problem but the engineers: they create it, they pay it down.