From a technical perspective, it's completely acceptable. This build was never intended to be released to the public, and so there was no expectation of backwards compatibility. It produces a new save, which the old build (by definition not patched to handle saves from the future) will then apparently choke on and mangle. Unless the mangling somehow avoids losing any information, or users' saves are backed up somewhere, I don't see what can be done in this situation.
The only thing I can think of would be to hold off on pulling the developer build until you've produced another retail build based on the last good one, with functionality patched in downcast saves generated from the developer build. But that kind of thing would probably have a minimum of something like a 1 week turnaround, which would mean leaving the development build live for a whole extra week.
In other words, the decision to immediately pull the developer build and revert to the previous one probably makes the corruption of saves inevitable. The only hope is that they pull it fast enough that as few users as possible are afflicted.
As for future-proofing against this kind of mishap (which falls in the general case of "Updates Breaking Saves"), you can use a versioning system that keeps saves from older builds around and writes to differently named saves with each new update. That unfortunately seems not to be what was done here...