Sure, but my point is, if the code is not well designed, the result of a ground-up rewrite will not be well-design either, for the same reasons which caused the scrapped version to be badly designed.
It is even likely the new version will be worse, since it wont be developed incrementally, and that harsh deadlines will be imposed when the organization realize they can't evolve the product as long as the ground-up rewrite is underway.
> Sure, but my point is, if the code is not well designed, the result of a ground-up rewrite will not be well-design either,
That doesn't follow for me, sorry.
A rewrite, as I understand and use the term, doesn't mean transpiling what exist to, say another language or to another framework. The old version is essentially just a very detailed and testable list of functional requirements; everything the old thing can do (as long as that functionality is still actually useful), the new thing must be able to do as well.
How this functionality is implemented in the rewritten version, and how it's internals are designed, is entirely up to the rebuild. The way functionality is implemented in the predecessor does not necessarily determine how it is implemented in the new version.
If the rewrite is by the same organization, the same forces which caused the first version to be badly designed will cause the rewrite to be badly designed.
It is even likely the new version will be worse, since it wont be developed incrementally, and that harsh deadlines will be imposed when the organization realize they can't evolve the product as long as the ground-up rewrite is underway.