The other kind of software debt

I think that Ward Cunninghams methaphor should stand like he intended it to be.

Other factors like the number of developers is external: There can really just be one facit to the problem domain, so there may be varying levels of technical debt throughout the codebase of a project, correlating to the members understanding. It is as simple as that.

The knowledge about frameworks, may also be viewed as plain technical debt, as this goes under the quality of how you solve your problem, or - it may be viewed as an external factor, and it is taken for granted that you use the frameworks, or have any necessary non - problem domain knowledge to solve your problem.

I think it is better to view it like that, than starting to complicate a metaphor that was good to begin with.