it's possible that someone uses the same ~/.gnupg with 1.4.x and 2.1.x.
if they use a secret key with 2.1.x then ~/.gnupg/.gpg-v21-migrated will be created.
if they subsequently generate new secret key material with 1.4.x, secring.gpg
will be updated, but subsequent uses of 2.1.x won't see that secret key material.
g10/migrate.c could improve this situation by comparing the timestamps between
.gpg-v21-migrated and secring.gpg, and re-attempting the migration if secring is
newer.
The README describes that this is a one time migration and that is a Good Thing.
Anything else means the addition of additional code and surprises for 2.1 using
applications by keys suddenly appearing.
The migration code is there to help the majority of users and not to help
speical use cases.
Those who really want to create new keys with 1.4 can use the standard way of
exporting and importing secret keys.
FWIW, I idle on gnupg on freenode and I've helped a bunch of people over the
past two years with exactly this problem. It is not that they want to use gpg
and gpg2, but that at some point they (or some tool) ran gpg2 while they
continued to use gpg1. They then became very surprised when they used gpg2 and
it only had a subset of their keys. My advice for these users is always the
same: remove the migration file and just rerun gpg2. As far as I can tell, this
has fixed the problem in all cases.
How many people has this happened to? how many people haven't known to find you
on freenode and ask about it? how many people have just given up on gpg
instead, or just decided "2.1 is broken"?
Shouldn't we fix this for them?
I fully support dkg on this. If our downstream is complaining that there is a
problem, then we need to take it seriously. I respect Werner's opinion, but
disagree specifically with the idea that this is only a problem for special
users. I think it will happen to many normal users too.