Is it an issue when you share an decryption key E among two smartcards?
I think that when there are six distinct keys (three subkeys for one smartcard each), it works fine.
I'll try to make reproducible test case.

For my test, six distinct keys (three subkeys for each smartcard) works fine.
IIUC, you try to use same decryption key by two smartcards. Currently, it is not supported.

Please show us your output of gpg --card-status for each card, and tell us the reason why you think "the pgp db seems screwed up".

That's exactly the point: I do want one common encryption key between the two cards: So I can distinguish between the two, but en-/decrypt with both.
One is on the GnuPG SmartCard, the other on a YubiKey - output --card-status (some things xxx'ed out) :

SC1 (GnuPG SC):

Application ID ...: D276000xxx
Version ..........: 2.1
Manufacturer .....: ZeitControl
Serial number ....: 00005xxx
Name of cardholder: My Name
Language prefs ...: de
Sex ..............: male
URL of public key : [not set]
Login data .......: myLogin
Private DO 1 .....: [not set]
Private DO 2 .....: [not set]
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key ....: xxxx FA81
      created ....: 2018-09-20 08:01:32
Encryption key....: xxxx B3BD
      created ....: 2018-09-20 08:02:52
Authentication key: xxxx A2AB
      created ....: 2018-09-20 08:02:06
General key info..: [none]

SC2 (YubiKey SC):

Application ID ...: D276000xxx
Version ..........: 2.0
Manufacturer .....: unknown
Serial number ....: 07326xxx
Name of cardholder: My Name
Language prefs ...: de
Sex ..............: male
URL of public key : [not set]
Login data .......: myLogin
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: xxxx F7A7
      created ....: 2018-09-20 08:03:16
Encryption key....: xxxx B3BD
      created ....: 2018-09-20 08:02:52
Authentication key: xxxx 7203
      created ....: 2018-09-20 08:03:45
General key info..: [none]

Why I think it's screwed up: because, as mentioned in the post above, it shows that all subkeys are on SC2 - instead of them being divided between the two of them.
Hence, to be able to use SC1 as "default", I need to restore the .gnupg directory to the state before writing to SC2.

If anything fails: is there any way to manually adjust the database (to adjust which keys are on which card)?

Thanks in advance, Chris

I would have thought this is a logical usage for gpg cards - seems this is harder to achieve as I thought.

It would be really helpful to at least have a way to manually adjust the database (or some other configuration file) - to adjust which keys are on which card / used for what.

Any hints on this front? Thanks!

Hello again - can I ask about the status? Or should I consider this as a no-fix? Anything I can assist with?

Thanks in advance,
Chris

It's complicated to have a good solution, because we need to change assumption (serial number identifies keys).

Today, I push a change to master, which relaxes the requirement. It does not fully fix your case, but it allows use of another card for different serial number.

Helo and forgive me for the ignorance, Iam a new.
I subscribed to this topic because I need a fix like that, I have 2 yubikeys with same subkeys...
Now how is possible to install from master; It's about a debian based distro. Also, when this will be pushed for updates via apt-get;
Thank you.

Thanks Gniibe San for explanation.

Yes, ok as long as it gets to masses one day. For most business and
household usecases disaster recovery in case the token got damaged etc or
atleast for the peace of mind and considering threat model its ok with risk
of painful initial cloning step using throwaway raspberry pi etc.. Fun
stuff.

Thanks for this @gniibe. I have long been frustrated by trying to save the correct "stubs" to have my keyring point at two different smartcards. It was common and even advocated in my former community to place one's master key on a separate smartcard (certify capability), with a different one designated for daily usage.

When having a backup media, I'd recommend completely different one (for example, on paper using paperkey to be stored in a locker in basement), which requires different method for recovering. Brains may be easily confused when same private key material exists in multiple similar devices.

I understand that it's convenient, and there are situations convenience matters (for easy recovering). Well, when using same media, I'd suggest to customize the backup device, by having different weight, different color, etc., so that it can be easily recognized.

Thanks a lot @gniibe for this change.
I do understand and share your concerns, nevertheless are there, in my opinion valid reasons to be able to have a backup or duplicate, especially on the same or similar media type.
Consider for example giving multiple devices a chance of common interaction, using the keys for backup encryption etc. - I think there are several possible use-cases which can benefit from this.