Sorry but as far as I'm concerned key management shouldn't be a part of the process that's handling connection authentications, etc. Why can't this be an outside protocol entirely? For decades, we've been waiting for some kind of automated decentralised, anonymised key-store and surely the effort going into securing this very dangerous piece of code would have been better put into moving the problem away from SSH and allowing multi-protocol use of such things.
If you trust a server by accepting its public key, it is by definition, trusted, for as long as its private key is secure.
Only the initial trust needs to be verified by humans, and with a chain of trust, even that can be nearly automated by adding your organization's CA key when systems are deployed (I'm in an imaginary world where SSH key management has caught up with the rest of the world).
The older a private key gets, the more likely it has been compromised, maybe by VM cloning, backup media leaking, etc.
To address that, you should change the keys periodically. Prompting the user is pointless, because the connection is trusted.
WHOA, let me back up a minute, you did know your session data is actually encrypted with symmetric keys right? ... and those keys are in similar fashion changed on a regular basis without your knowledge?
If you didn't know that, well.. that explains 99% of the ignorance I'm seeing on this page.
SSH's key management is an absolute joke, but this is a step in the right direction at least. The only thing I can imagine is the authors figured people would be using kerberos in all but the smallest shops... and I'm being nice assuming SSH's kerberos integration is any good.