I'm unsure what this discussion is about? Is it talking about different validation methods outside of the standard host key checks or talking about changing the existing implementation which sounds like what you've described?

Three scenarios:

1. Standalone system somewhere, use SSHFP (if possible with dnssec). If no dnssec is available only use it to detect a mismatch (and show an error if they don't match) but still show the warning, as we don't know if that information is trustworthy. If dnssec is valid and keys match also silence the above warning on first use. If dnssec is valid but keys don't match show an error.
2. System is part of the same (maybe also use trusts, but that doesn't translate that well to non-windows systems) LDAP(S), query the computer object of the remote system, and look into a (newly to be defined) attribute to validate that this is the correct SSH key. Similar to how a Microsoft active directory currently stores S/MIME certificates for users.
3. Part of the same Kerberos realm (or a trusted for cross-realm) => Rely on GSSAPI and (MIT-)Kerberos to validate the host instead of relying solely on the SSH key.

OpenSSH already has a mechanism besides fingerprints to verify user and host authenticity via certificates.

Are you looking to improve that/the user experience around this? There was even a recent discussion on Hackernews following the GitHub RSA rotation.