Software does not have a sense of elegance, and short of a strong AI, it cannot ever have a sense of elegance. The kind of technical debt that matters is mismatches between program abstractions and target domain abstractions. What this does is more like using a spell checker to determine how close a book is to being ready to publish - fundamentally misguided at best.
I wish you could flesh that out a little and forward it on to the folks ensuring the software we write at work is "high quality." I keep telling them that metrics and unit tests don't make a quality system, a good design and bug fixing does.
But applications with good design always have good metrics and unit tests ... The technical debt can't say that an application has a good design but it can say that it has a poor one.
I don't know any spell checker which is able to give you the amount of duplicated code, code coverage by unit tests, ditribution of complexity, ratio of documented api and so forth ;-).
Yes, I was hoping to create a conversation here with this seeder list. There doesn't seem to be much interest here though. :-)
BTW, number of bugs should probably be weighted with number of incidents for each bug and its impact. The mere thought of this makes me rethink my design - how will know the number of incidents? Should I instrument my code to download "bug signatures" and report back the findings? For a web app it seem a straightforward thing to do. How would I do this for desktop/iphone app? I could proably send down some script code to walk over the local storage to look for problems. How about UX bugs though? Should I log UX interactions into a local database and send down queries as well? Hm...