to explain a bit more: This report was opened after the reported defect was already fixed.
As we are getting many reports and technical suggestions, please keep the reports focused on one point only if possible
and open general discussion points about development improvements on gnupg-devel@.

Can you point me to a more elaborate list of the general concerns? (Central directories offer some sort of stable history, namespace and API service towards identifying modules, just like the venerable https://www.ctan.org/ . The solutions built on such services, like programming environment specific "package" and dependency managers that download and install thousands of packages automatically (like yarn) may be debatable, but I am not aware of much general concern against the services itself.)

@werner, that is a missunderstanding:

I may attempt an update here, who has the pypi maintenance account?
(If we don't have it, we need to ask Justin or create a ticket with the PSF.)

The user reported to

Hi Werner,

can you elaborate?

A backtrace with gdb from migw-w64 results in

I did a fresh install of Gpg4win 3.1.14 and imported my standard pubkey, by using

gpg --locate-key bernhard@intevation.de

on the command line.

@s7r Thanks for testing and letting us know!

Thanks Werner! Seems like an important step!

Thanks for the quick analysis.

Observation:
The umlaut is displayed incorrectly on the command line (cmd.app) when the keybox file is created.
(This may or may not be relevant.)

Last report more than two years ago.

--locate-external-keys exists since 2.2.17 and ignores the local keys.

On the ml there was another request for this use case

Read through it, thanks for the updated description!

Thinking about the logic from an email application viewpoint:
To display what will happen, I want to know if I can encrypt to an email address and what trust level I have in the public key I'll find.

Hello,
just reading the issue in detail.

Just reading this issue in detail.

@dkg while I agree with your aim of

Just added a comment to T4826 how to move forward, if this is still interesting for parties. Right now (from my point of view) a pubkey with an expiration date beyond 2106 is not a sensible key configuration, so the use to motivate a chance in this area would need to be argumented better.

This issue, as well as T4766 has the challenge that there is a disagreement about the usefulness of the use case, as far as I can see.

To explain the use case, I've started coming up with a good passphrase and this took a bit of time with a pencil and paper in front of me. When I wanted to type it in, it was too late. Thus I guess that some people will look up good rules of passphrases or at least make sure they can remember the one they are typing in.

How do I know that you've noticed?

@aheinecke thanks for commenting.

Taking a look at other GNU manuals, both GNU make and GNU Bison have a better phrasing,
so I suggest the Bison way (https://www.gnu.org/software/bison/manual/html_node/index.html):

This manual (7 December 2019) is for GNU Bison (version 3.5), the GNU parser generator.

Ah, okay, then the phrasing is missleading, the sentence looks like libgcrypt was released on this date and not the manual.

(Found while trying to answer a user question at http://wald.intevation.de/forum/forum.php?thread_id=2140&forum_id=21&group_id=11)

Okay, maybe this should just be added to the 2.2.x docs.

Thanks for your comments. It would have been cool if this restriction would have been noted
in the gpg options documentation. (Where is was missing at least where I was looking.)

Changed to Issue Tracker with 1d89f93b037d0f7cd084dbc7873f73134a8e1f1a.
@olf thanks for the hint.