I tend to agree with Owen about focus and scope with the transfer stuff - keeping a keen focus on getting things done. You're raising good points and thinking of the registrant, which is something that is good for us all to be doing.
Considering the things you are raising is helpful to factor in along the way so we don't complete our process with zero awareness of DNS information transfer, but the focus seems on the Registration vs the Resolution parallel paths of transfer, because that's been what is in focus with all the EPDP _stuff_ and the transfers happen most entirely within the SRS on the registration side. Auth-Info Codes, Status Code lifecycles, validations, etc. are all in the EPP/SRS world.
DNSSEC _might_ creep into scope due to the way DNSSEC was put into the world. The registrant's registrar for a given domain is the only path to adding the records for a given name to the registry. Most folks get this set up at the gaining registrar or 3p service and then update the info on the losing registrar early or pre-transfer.
With respect to transfers on the rest of the Resolution side of things.... Typically, in a transfer scenario, the DNS resolution _stuff_ is addressed by the registrant as a separate and sometimes parallel project path.
Also typically, the gaining registrar gets set up first with the DNS zone, either record by record through painful user interfaces or in whole zone fashion, OR there is a third party DNS provider being used so the name move really is completely separate.
If one looks at the process through a commercial lens, the gaining registrar is motivated more than the losing registrar to help or develop tools for this, which I can't fault the logic of. That said, most registrars in the RrSG go out of their way to help their customers/registrants where they can due to the relational nature of the business.
-J
Jothan Frakes