• The problem with this is that you need to know *when* N signed N+1, and you can't believe N about the time.

Out of band verification. You make sure the chain you have connects properly up to the current KSK.

Then its "Turtles all the way down". https://en.wikipedia.org/wiki/Turtles_all_the_way_down

At some point you've involved something outside of the DNS and you need a way to trust them, and a way to supercede the trust if they're compromised.  Or you need a crowd of them.  Etc. 

I thought of time stamp services - those might work but have the same problem of root management  for their chain of trust - e.g. the resolvers need to be able to get the most recent trust anchors before they can validate the DNS trust anchor set....   What I'm actually thinking about is some form of inserting a record into the blockchain ledger for one of the cryptocurrencies as a mechanism for time stamping the state of the trust anchor set at a given point in time.  See references 2 and 3 of https://en.wikipedia.org/wiki/Trusted_timestamping

But that's complex and probably requires that the root key holders add another step to the process of managing the keys.  It's not something that's a simple add on.

Or you tell folks turning on old computers to just reconfig first. :)

That gets my vote.  Or  - they just down load all the security patches that have been signed with the vendor of the devices private key to include the new starting trust anchor set.

Later, Mike