Here is my understanding:
--log-file option is valid for for background task like gpg-agent, dirmngr and scdaemon.
For gpg, it only works with --batch or --server.

This will be in 2.2.18, closing.

In my own opinion, it will be good when desktop environments support GnuPG as one of first class citizens, to protect user's data.
For example, currently, libscret stores secret data (such as WiFi shared secret, etc.) by its own cipher preference and method (and it is symmetric cipher by user's password). I don't think it is secure enough.
For me, it will be good if it is protected by user's gpg key using asymmetric crypto.

Sorry in advance for long explanation. :-) Well, let me show my stand point at first (to avoid confusion): I don't like the concept of "desktop integration" when it makes difficult for a user to control his environment.

Could you try to put no-allow-external-cache in your gpg-agent.conf?
If it changes the behavior, it is your desktop environment which caches your input, I suppose.

I thought I close this after the release of 2.2.18.
Anway, it's done, so, closing.

Sorry, it was simply my confusion (between GEMPC_PINPAD and GEMPC_EZIO).
Fixed now.

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.