Issue replicated: User error.

gpg -K lists only private keys.
gpg --edit lists both public subkeys and private subkeys but does not
distinguish when the secret subkey is missing.

This is what it looks like when you export the public subkey, delete the
secret subkey, then import the public subkey.

tl;dr: PEBKAC

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.

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.