gpg lets the user use policy compliance options like --rfc4880 or --rfc2440 or --openpgp or --compliance de-vs. the documentation claims that "Only one of these options may be active at a time." but the tool itself lets the user specify multiple options, like so without complaint:

gpg --compliance de-vs --compliance gnupg --decrypt

In addition to setting cryptographic and wire format policies, these choices also adjust parameter decisions, like the default cipher used with s2k (which can also be set with --s2k-digest), whether to strip trailing whitespace when making a canonical text document signature without using the CSF (--rfc2440-text), or whether to require a cross-certification (--require-cross-certification).

However, it's unpredictable which of these various policies and configuration choices take effect when two of them are in conflict, and gpg doesn't warn the user when a conflict arises.

For example, when making canonical text signatures over data that has trailing whitespace, these commands will all strip the trailing whitespace:

gpg --text --armor --rfc2440-text --sign
gpg --text --armor --rfc2440 --sign
gpg --text --armor --rfc4880 --rfc2440 --sign
gpg --text --armor --gnupg --rfc2440 --sign
gpg --text --armor --rfc2440 --gnupg --sign

while these commands will *not* strip the trailing whitespace:

gpg --text --armor --sign
gpg --text --armor --rfc4880 --sign
gpg --text --armor --gnupg --sign
gpg --text --armor --rfc2440 --rfc4880 --sign

That is, --gnupg does *not* override --rfc2440 when it follows it, but --rfc4880 *does* override --rfc2440 when it follows it.

Similarly, the default symmetric cipher and hash used for symmetric encryption interact strangely with the order of different options.

One part of this appears to be that --gnupg (and its synonym --compliance=gnupg, as well as distinct options --pgp7 and --pgp8) only set opt.compliance and don't update any of the more granular opts fields directly, in theory leaving the rest of opt set to the default values set at the top of main(). But if one of the other options that sets granular opts fields is invoked first, then --compliance=gnupg cannot restore those choices to their prior defaults.

And, then again, there are some granular opts fields that are never touched by any of these "compliance" options.

At the very least, it seems like gpg should warn the user when two incompatible --compliance options are in effect at the same time.