During root update, should we purge trusted timestamp/snapshot after key rotation earlier in the process?

I finally had a little time to work on rust-tuf, and I noticed in 1.0.34 the spec states that we purge the timestamp/snapshot metadata on key rotation:

...

7. Set the trusted root metadata file to the new root metadata file.

8. Persist root metadata. The client MUST write the file to non-volatile storage as FILENAME.EXT (e.g. root.json).

9. Repeat steps 5.3.2 to 5.3.9

10. Check for a freeze attack. The expiration timestamp in the trusted root metadata file MUST be higher than the fixed update start time. If the trusted root metadata file has expired, abort the update cycle, report the potential freeze attack.

11. If the timestamp and / or snapshot keys have been rotated, then delete the trusted timestamp and snapshot metadata files. This is done in order to recover from fast-forward attacks after the repository has been compromised and recovered. A fast-forward attack happens when attackers arbitrarily increase the version numbers of: (1) the timestamp metadata, (2) the snapshot metadata, and / or (3) the targets, or a delegated targets, metadata file in the snapshot metadata. Please see the Mercury paper for more details.

I'm wondering if we should move step 11 to right after (8) we persist root metadata, rather than as the last step. That way if we run into an error during the root update cycle, such as if the one of the following root metadata is malformed we won't have a mix of a new trusted root with old metadata?

Start with the Update Root section of specification v1.0.34, especially steps 7–11 and the linked Mercury paper. Compare the proposed ordering of timestamp and snapshot deletion with the described failure scenario; done means reaching a decision and recording the agreed specification change or rationale.