Thank you @dkg for creating the bug report! I would like to glean the following information from the above mentioned discussion.

I was able to reproduce this behavior on a system which uses the configuration file gpg.conf (see below). I tested this with GnuPG 2.1.18 and 2.2.12.

Preparation

Use the following configuration in $GNUPGHOME:

rm msg.*
echo "hello world" > msg.txt
gpg --batch --yes --delete-keys edward-en@fsf.org

Bad Case (does not work)

gpg --always-trust -e -r "<edward-en@fsf.org>" msg.txt

	gpg: <edward-en@fsf.org>: skipped: No public key
	gpg: msg.txt: encryption failed: No public key

Good Case (works)

gpg --always-trust -e -r "edward-en@fsf.org" msg.txt

	gpg: key 9FF2194CC09A61E8: 7454 signatures not checked due to missing keys
	gpg: key 9FF2194CC09A61E8: public key "Edward, the GPG Bot <edward-en@fsf.org>" imported
	gpg: no need for a trustdb check with 'always' trust model
	gpg: Total number processed: 1
	gpg:               imported: 1
	gpg: automatically retrieved 'edward-en@fsf.org' via keyserver

Note: The only difference are the wrapping angle brackets.

According to the the test data set posted by @werner the form of the addresses should be accepted. I suggest to also adjust the part of the GnuPG manual to all designated forms.

Is this task maybe related to T1927?

This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.

In T4726#130341, @werner wrote:

This is a misunderstanding. The extraction of mail addresses is only doe for key lookups on remote services. Thus the -r case is as intended.

I am confused: The lookup described above (T4726#130327) is performed via keyserver (see output of good case). Is not that meant by remote service? Please excuse my lack of knowledge.

@werner, you seem to be saying that -r does not imply "key lookups on remote services". Is that correct?

Due to the fact that --auto-key-locate can include a lookup to a remote service based on the recipient address, shouldn't the same rules apply? what mental model do we expect users to have here?

-r  STRING

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup. This was implemented in this way to be as much as possible backward compatible.

In T4726#130609, @werner wrote:

-r  STRING

does a remote key lookup only if STRING is a valid addr-spec. No extraction of the addr-spec from STRING is done and thus angle brackets inhibit the use of a remote lookup.

Thank you for clarifying the status quo. Fortunately this matches this part of the GnuPG manual when reading closely.

So is this the desired behaviour for the future and this issue should be closed; or shall this behaviour be changed in the midterm? I would very much appreciate a conclusive verdict on this issue.

Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example). The risk of a regression in that case is pretty low.

If there is more than just the angkle brackets we would need another option to allow for this. Otherwise too many use cases, where the uid only happens to include a mail address, would suddenly go out for a network search.

To answer your question: With the exception of case two this is desired behaviour also in the future,

In T4726#130765, @werner wrote:

Given that the the angle brackets are elsewhere used to indicate a search by mail address, it would be okay to allow for them in this case too (that is dkg's second example).
[...]
To answer your question: With the exception of case two this is desired behaviour also in the future,

Thank you @werner for clarifying and allowing that exception! An implementation, which would accept a form with angle brackets would solve a interoperability issue I observed with Evolution in order to automatically obtain the PGP keys when sending e-mails.

Thank you for resolving this issue! I am successfully using version 2.2.19 from the gnupg (2.2.19-1~bpo10+1) package of Debian Backports.