All reasonable suggestions except the versioning bit. Perhaps every long while you replace one api with another. In that case you either keep supporting to old one or force clients to move to the new one. But while you have an api you have to keep your interfaces constant, support all the old signatures and add new ones as necessary.

"In a true TDD method, we end up not writing any code at all until all the test cases are written and are working" What would such tests even be making assertions against? Also the question is is not whether testing increases the amount of work "testing should be 50% of your work". It's about what happens when a large refactoring of the code base necessitates an equally large refactoring of your tests. This can be a problem, and it used to happen to me more when I would come up with complex abstractions, class hierarchies, etc to model solutions. It's something I would just have to suck up. Since I've turned to an increasingly functional style of programming (small single purpose functions composed into pipelines-- pure whenever possible), I find this happens less and less. This is because refactoring largely becomes a matter of recomposing the pipeline. I seldom have to go back to rewrite any existing unit tests.