21f7ad563d9b was not backported to gnupg 2.2, so this can't be done yet

The commit rC58c11aa8 is the improved version by k-ary exponentiation (while rC6dffd105e2e2 is 1-bit at a time) and using heap.

It's missing a check for the required gpg-2.2 version. I will add that

Closing as there are now 2 follow up tickets for the open issues I found.

The wonders of Windows! Who knows which overzealous component of Windows deleted this file. I suspect that your virus scanner wrongly suspected the file to be malicious (false positive) and removed it. Kleopatra certainly doesn't delete any of its files itself unless you uninstall it. Since a reinstallation (as proposed by Windows likely because vanishing files is a common problem on Windows) solved your problem I'll close this ticket as resolved.

This issue occurs when using GPGME with multiple contexts and setting the OpenPGP engines to different GnuPG home paths. As you mentioned, it is crucial to let gpgconf know the correct home path so that it can locate the socket file used by gpg-agent and properly clean up all instances.

Signs from the past or is this due to fixed Observer URI I did this morning in this repo?

gpgconf assumes that there is only one of the daemons. In fact it can only work with one and that is the one daemon which listens on the socket. all daemon's do a self-check by trying to connect to themself and terminate if they realize that they are not anymore the owner of the socket. As long as a daemon is started by a gnupg component a file system lock is taken to avoid duplicate launching. However it a daemon is stared by other means this could lead to a race.

VS-Desktop-3.3.0.0 now has the translation. Will be in Gpg4win in the next release.