gpg2 can't use that as the agent is a hard requirement. The only reason for
keeping the passphrase callback is for symmetric encryption.

Although gpg2 currently uses the agent only for passphrase caching, it will soon
move all its secret key operation to gpg-agent and then there won't be any way
to have a passphrase callback.

Oh, interesting. How do you plan to handle common problems like no pinentry
configured (or even installed because distros don't make gnupg depend on it) ?

As a developer of Claws Mail, I also find it very frustrating to have this
functionality removed. My passphrase dialog pops up in a tenth of a second,
whereas pinentry-gtk-2, with all the process creation, library loading etc,
takes 1.5 second to appear.

The first is a problem of the distribution. Distributing gpg2 without a
properly installed pinentry is just stupid.

My pinentry pops up much faster. There should actually be not a lot of libaray
loading because the GTK+ libraries are already in memory. There might be a
problem with the linux kernel in case you have not used gpg-agent for a long
time and it has been pro-activly paged out. Did you tried the gtk-1 version?

Just to be sure: gpg-agent is running and is not loaded on the fly when a
passphrase is requested? An indication for the latter is a non-working
passphrase cache.

I'm happy to see GnuPG moving to an all-agent model, where the passphrase and
the asymmetric secret key material aren't available to the gpg process.

That sai, if gpgme is going to remove the passphrase_cb prompt, or to deprecate
it in all cases other than symmetric data encryption/decryption, then should the
API change?

gpgme_set_passphrase_cb is used in about 40 packages in debian:

  https://codesearch.debian.net/results/gpgme_set_passphrase_cb/page_0

this includes bindings for python, ruby, php, and c++ -- and it's possible that
those bindings themselves have some other usage elsewhere.

Do we have guidance for users of this function, whether it's with gpgme
directly, or with any of the bindings?

https://pagure.io/pygpgme/c/6648b075fb3d434c599d7e1793bd1f0bbe85dfe3?branch=master says:

T767 indicates that

gpgme_set_passphrase_cb is a deprecated corner of the API and that
developers using gpgme should really rely on the gpg-agent to handle
this stuff.

That is not correct. gpgme_set_passphrase_cb is not deprecated, and gpg21 does honor the flag.
In fact, allow-loopback-pinentry is the default since GnuPG 2.1.12.