Today, I had to delete and recreate a migration four times (twice because a TextField was used instead of a CharField, once due to a typo in the field name, once because the need for additional fields came up during implementation).
To be honest, I don't really understand how people do not run into this sort of situation, unless one is just creating a separate migration for each fix. However, that's clearly bad in so many ways (ugly, harder to follow, more possible failure points etc.) and South shouldn't encourage it.
A switch like that would would it easy to incrementally work on a database migration as part of some new feature or change, and then commit a single migration that contains the final changes.
Of course, migrations that have already been distributed should not be changed, but it seems reasonable to trust developers to use the option responsibly, just like we trust them not to edit such an existing migration manually.
I've accepted this as the code ends up being reasonably simple, and because in the two years since issue 269 I've observed that the most common stupid things done with South are elsewhere, and that this would probably help some people.
It does need some documentation, though - I can write some when I get around to the next release cycle, but if you feel like adding some to the docs in the repo now that would help a great deal!