caching_sha2_password vs mysql_native_password: choosing a default for MySQL 8.0 legacy client support

MySQL 8.0 changed the default authentication plugin to caching_sha2_password, which mandates TLS or RSA key exchange during the handshake. Legacy clients and older connectors that do not implement this plugin cannot connect, producing an authentication plugin load failure. The alternative is mysql_native_password, which remains accepted but is deprecated and offers broader compatibility with existing drivers and applications at the cost of a weaker authentication mechanism.

The decision is complicated by version-sensitive server behavior. Early 8.0 releases rely on default_authentication_plugin as the primary switch, while later minor versions introduce authentication_policy to govern plugin and factor rules. Creating individual accounts with IDENTIFIED WITH mysql_native_password is a documented workaround, but it fragments security policy across the user base. The active control variable depends on the deployed 8.0 minor release and should be confirmed against the server version before committing to a policy.

Should the environment standardize on caching_sha2_password and force client-library upgrades, or retain mysql_native_password as a transitional default for legacy compatibility? Which server variable or policy setting controls this behavior in the specific 8.0 minor version in use? How can the trade-off between uniform security policy and broad client support be resolved without per-account exceptions?