This continues my dive into the --compliance policy mechanisms.
When a user does gpg --compliance=rfc4880 --quick-gen-key they are probably expecting to create a certificate that is compatible with other implementations that target RFC 4880.
Instead, they get an OpenPGP key that uses ed25519+curve25519. It seems like if the compliance mode is rfc4880 (or rfc2440 or pgp8 or pgp7 for that matter), the generated key should be RSA+RSA.
i see two forms of an initial resolution here: one is to have set_compliance_option always explicitly set opt.def_newkey_algo. The other is to check opt.compliance in get_default_pubkey_algo.
Additionally, It seems like if the user is asking for --compliance=rfc4880 (which says "strict" in the documentation) then even if the user explicitly asks for an ECDSA key (or any other pubkey type not defined in RFC4880) GnuPG should complain that it would not be in compliance.
The compliance mode likes 4880 or 2440 are only here for backward compatibility in case that is needed. New keys shall always be generated using the current default algorithms. Note that a mode like de-vs is different in that it is used to comply with certain regulatory demands and not as a backward compatibility hack.
Maybe we have a different understanding of what "backward compatibility" means. if someone needs backward compatibility to communicate with someone using an RFC 4880 client, then surely they don't want to use a pubkey algorithm that isn't specified in RFC 4880, right?