A title or an URL does not make up a a proper bug report. Please describe your
bug here. tia.

Issue: I get a different list of secret keys when using gpg -K than gpg -
edit, and the missing keys can no longer be used to decrypt. I'm using
Gpg4win on Win10 with the latest stable build, but downgrading to previous
versions doesn't help. Adding new keys and removing newer keys doesn't help.
(There was once a [Debian?] bug which only listed the latest key, but this
appears to be different.)

User error is a possibility.

The attached file (gpg_K-vs-edit.txt) shows the results from gpg -K and gpg
--edit with the keys substituted for easier reading. You'll notice that
44444444 and 55555555 are missing from gpg -K.

2.0.12 is a 7 year old version you should not use it at all.

The secring and the pubring in versions < 2.1 can go out of sync for various
reasons. I can't tell from the lising why this is the case, if you can repeat
that with the 2.0.30 version, we can be sure that it is not one of the hugs
fixes in the last 7 years.

Attached: repeated using 2.0.3 and keys imported from armored backup.

More details:
The issue arose recently, after the subkey had been used for many months
(but IIRC before the subkey expired). The issue affects both the headless
keychain and the master keychain. The restored "backup" was an armored
export, not a whole keychain.

If werner hasn't heard of something like this, I'm doubling my bet on user
error. Maybe my key storage process is the culprit? These keys were
accessible on different TC encrypted partitions, but there is an unencrypted
backup drive elsewhere. I'll try restoring from that.