Or... it could be a feature, not bug, so that failure of -e -r someone can be examined by --locate-keys someone.

Let me clarify the point.

I think that we should apply further change:

diff --git a/g10/getkey.c b/g10/getkey.c
index 077209415..1c337149c 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1369,7 +1369,7 @@ get_best_pubkey_byname (ctrl_t ctrl, enum get_pubkey_modes mode,
     *retctx = NULL;

I found more wrong cases of get_best_pubkey_byname.
For ranking results,
(1) It may return non-encryption primary key as the most relevant key, when its validity is higher.
(2) It may not select encryption primary key even if its creation time is newer.

In my opinion, --locate-key should locate encryption key.

@pow, thanks for a reference. But problem here is that there are multiple products with same name.

I believe that constraint of ret_keyblock != NULL is OK.
Pushing the fix.
Perhaps, backport to 2.2 should be done, too.

If we can assume ret_keyblock != NULL (it is, in current implementation), it can be as simple as:

diff --git a/g10/getkey.c b/g10/getkey.c
index 6802026f6..27bbd354c 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1354,6 +1354,8 @@ get_best_pubkey_byname (ctrl_t ctrl, enum get_pubkey_modes mode,
   int is_mbox = is_valid_mailbox (name);
   int wkd_tried = 0;

I modified _gcry_ecc_fill_in_curve so that g_y has new value in eid4730.

That's my badness. I think that I haven't seen this problem, because I mainly use tokens (where keygrip difference doesn't matter, after --card-status).

OK, I identify the problem.

For pinpadtest.py, you need to offer an option --add (adding dummy byte), when you are using Cherry ST-2xxx.

It is not supported, by CCID protocol itself. So, it is not supported by scdaemon, and by any of card readers (which I know of), either.

And it is merged into master.
Along with the support of multiple readers/token, the parts which assumes Windows 32-bit are fixed, too.

For argparse.c, it can be only stopped with nonnull attribute for the API, I suppose.

I take this so that libgpg-error can be released soon.

I created a branch for this task: https://dev.gnupg.org/source/gnupg/repository/gniibe%252FT4620/