I understand the real world requirement for decrypting messages that have been encrypted to a revoked or expired key.

In that use case, if the thing being decrypted is believed to be more recent than the revocation or expiration (which we can't really tell, because OpenPGP has no place to assert such a "freshness/age" on an encrypted blob), then a minor warning sounds reasonable.

The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.

If a user decrypts a message, a sensible tool will give them a warning if the message was decrypted using a mechanism that they did not expect to use for decryption. gpg should at least provide hooks to indicate such a warning, so that the user-facing tool can decide what to do about it.

The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.

I agree.

If a user decrypts a message, a sensible tool will give them a warning if the message was decrypted using a mechanism that they did not expect to use for decryption. gpg should at least provide hooks to indicate such a warning, so that the user-facing tool can decide what to do about it.

I disagree. A key that isn't supposed to be used for decryption by its generation parameters absolutely shouldn't be used for decryption. Not with a warning, not ever. Unlike expired and revoked keys, there is never a valid reason to do this (discounting "bug compatibility"), and oracle situations or unintended interactions between algorithms is why we are splitting up keys into signing and encryption in the first place. Ignoring that distinction on the receiving side gives an attacker completely unnecessary wiggling room.

Please reconsider.

i agree with @Valodim that it would be better to not have a warning at all for an attempt to decrypt from secret key whose public key has never been marked as valid for encryption. A strict failure there (as with a strict failure for lack of mdc) is a better scenario than a warning. If the user controls the secret key and they decide they want to be able to decrypt with it, they should be able to mark it as decryption-capable (if that's really what they want) and retry. But this is an action only for experts.

There may be some circumstances where gpg might not know whether a particular subkey has ever been marked as encryption-capable (e.g. maybe it used to have that usage flag, and someone updated the usage flags and cleared the history of subkey binding signatures). In that case, i think it's ok for gnupg to refuse to decrypt with that subkey, even if there was some point in the past where it was known to be encryption/decryption capable, because gnupg simply doesn't know about that old usage flag marking.

I disagree, and you don't have to try to convince me, the decision is with werner. I just want to give my opinion:
Bug compatibility is nothing esoteric or bad especially for a general purpose backend tool like gnupg. Being open to accepting broken input is a good thing because it will mean that we can get people out of a "broken tool vendor lock in".

As long as there is no security concern GnuPG should be lenient in what it accepts. Having an error will mean we get yet another "ignore-usage-error" option and if it happens enough we have to handle it in the GUI like "ignore-mdc-error" making everything more complex.
There will be important data around for some people that is encrypted improperly. For them not being able to decrypt their data starting from version X will cause them either to use version X-1 or land in support because they won't know what to do.
I do not have anything against a warning.

There is another argument for respecting the usage flags: it trims the admissible key space, if key ID in the PKESK packet is zero ('wild card') and thus all private keys have to be considered for decryption.

Fair enough. Let's wait and see what others think.