Here's all of the above patches squashed into a single patch:

attached here is a series of 4 patches that reinforce that the last --compliance policy option (or equivalent option, like --rfc4880 or --gnupg) supercedes any earlier one.

sorry for the confusion in the initial report -- the policy compliance option is of course --compliance, and not --policy, and i just miswrote it in one line of the description above. I've corrected it now, and all the rest of the report is still as it was.

Ok, then this will not be included in the VSD versions until we switch away from gpg 2.2

That gpg seems to be some other or patched software than the one from gnupg:

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.