Sorry, I think you have to fix the other tools. The ! suffix has virtually been supported forever and any new option to do the same complicates the code and the documentation.

gpg selects the newest encryption subkey. In you case it is hard to see which one this is. If you use --with-colons or --full-timestrings you should see the entire timestamps down to the second.

Thanks for the reply :)

Okay, I can understand that. But I would love to know if that means there is a good workflow how to deal with this scenario:

I add a new subkey on my main machine for a new android phone, then import it's public key to my laptop.
The key will this be newer and now used when encrypting on my laptop, but my laptop can no longer decrypt, because it doesnt have the private part.

It it just that I'm misunderstanding something about gpg workflow / subkey concept?
Or are subkeys not really meant for multi device usage?
Or should I adapt all tooling to work directly with subkeys? (Which is quite a challenge as many tools don't seem to - an exclamation mark in the key ID is considered a problem)

Thanks in any case and I'm ready to out in some work for the most important tools (like gopass), but even my nextcloud client using kdewallet is now not working anymore, seemingly because it does not support subkeys correctly.

What do you want to achieve by using multiple encryption subkeys? Do you realize that gpg will always encrypt to one subkey (unless you explicitely specify multiple subkeys), i.e. you won't be able to decrypt on device 1 what you have encrypted for device 2 and vice-versa. Usually, this makes little sense because it seems you want to be able to decrypt anything on your main machine.

If you really want two different encryption keys, so that you can seletively encrypt stuff for your android phone, then you are probably much better off creating a completely separate key for use on your android phone.

I've read many articles mentioning the improved key handling when different devices just have different subkeys, thus allowing a semantic connection to a primary identity (instead of different "Identities" on different devices)

I found those two on a quick search:

• https://security.stackexchange.com/a/31598: "Examples for using subkeys:
  • You want to use multiple keys for multiple devices (so you won't have to revoke your computer's key if you lose your mobile)
  • You want to switch keys regularly (eg., every some years) without losing your reputation in the Web of Trust"
• https://security.stackexchange.com/a/59083: "Do not create multiple keys. People will be confused over which one to use."

And I love the idea of not having semantically separate keys, but only subordinate keys that semantically belong to my main one. Upon realizing the tooling doesn't seem ready for this I asked myself: "Should I drop the idea - or can I improve the tooling to support this ideal?"

I think a lot of tools that are subkey-agnostic would benefit from gnupg allowing to specify a certain subkey as default for the usage type.

But I do realize it will also be necessary to teach some tools about subkeys - e.g. I want to be able to tell gopass it should encrypt for my laptop subkey and for my phone subkey.

I see that this won't be the only thing necessary for this key strategy to work - e.g. I need to be able to tell other people to encrypt against a certain subkey (e.g. a subkey I created that all my devices have the private key for, so people can send me files/emails and I will be able to read them on all devices), but it would be a great start.

I think it's a bit outside my competencies to submit a patch for this, so I will accept if you don't seem it is useful for gnupg. But I thought if you considered the use-case I have and that seem to be also flying around the web as an idea (albeit with warnings about the incomplete support), you might agree it would be great if subkeys came closer to their potential of enabling composable uses for keys while maintaining a semantic connection to the primary identity.

Debian's wiki also speaks a lot about the advantages & dream of subkeys, but also mentions the caveat:

If you have multiple encryption subkeys, gpg is said to encrypt only for the most recent encryption subkey and not for all known and not revoked encryption subkeys.

Wouldn't it be great if this caveat would cease to be one?
And yes, this needs more than just my request, but that's why I'm enthusiastic about it 😅

The reason why gpg does not encrypt to multiple subkeys is that the older subkeys are viewed as deprecated. You could write a tool which does a heuristic to check when the time is reached that no more messages are encrypted to an older subkey (or are used to decrypt archived mails). At that point you can take the private part of the old subkey offline.

What we have on our shortlist an new type of subkey flagged as archive-key. gpg would then also encrypt to those archive subkeys. This mechanism can as well be used to decrypt using anotehr subkey on a second device. The is done using a new key flag:

Second octet:

    0x04 - This key may be used to encrypt communications or storage.
[...]
The "restricted encryption key" (2nd,0x04) does not take part in any
automatic selection of encryption keys.  It is only found on a subkey
signature (type 0x18), one that refers to the key the flag applies to.

That sounds like a great (and better) solution! Thank you for your attention & effort 👍🙏