New Situation
Once I started testing in logging mode the problem had gone away already. There were some hints to HTTPS certificate issues, but nothing really to blame. Neither with nor without logging the problem could be reproduced after two days of questioning me.

The caching works on the base of the requested domain, that is example.org and not openpgpkey.example.org - thus it should not make a difference when you change your setup. There is an initial test for a cached domain status before the resolving process starts. If you want to look yourself: gnupg/dirmngr/server.c:cmd_wkd_get() and domainfo.c.

Reproducibility
The problem cannot be confirmed generic on domain level. I can reproduce the effect with keys shipped from my domain, i.e. email addresses @shimps.de, but the issue vanishes when I try to reproduce it with email addresses @gnupg.org as e.g. Werner's address.

I have now disabled the rewriting in the 2.4 branch. Those who want to keep the old behaviour may add

I will review the issue. A likely outcome will be to follow your suggestion but to add an option for the old behaviour to avoid further security discussions.

With 2.4.1 you will get a runtime error

sendmail tool '%s' is not correctly installed\n

The current WKD/WKS draft offers no direct guidance to WKD clients about the type of filtering they should do.

No. We now ignore expired key with --mirror, --create, and --install-key.

You get this error because the key has been created in gnupg mode (and not in de-vs) and thus it has these preferences.

I don't think that we need to fix things here. Important is that the WKD import uses a filter which imports only keys with the requested mail address. However, if a key with the same fingerprint already exists it will be merged.

Fix will go into 2.2.37 and 2.3.8.

Probably fixed meanwhile in 2.2.
Please re-open if experience this problem also with a decent gnupg 2.2 versions.

This problem does not seem to exist in GnuPG 2.3.6.

gpg tries to find the "best" key using get_best_pubkey_byname (https://dev.gnupg.org/source/gnupg/browse/master/g10/getkey.c$1507), but the applied rules are not clearly documented in one place.

I don't like it either but the browser vendors don't like SRV records.

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

Thank you, works now on Windows with openpgpkey.sanka-gmbh.de

Independently of that, it seems that gpg4win doesn't work with at least one widely deployed webserver in its default configuration, specifically Caddy, so this fix is well appreciated.

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

Oof. That hinges on the certificate, guess we'll need to renew the bunch of them. I reconfigured, might take a while for all pages but ciphers should now be:

The ECDHE_ECDSA suites are not yet implemented in ntbtls and thus we can't agree on a common cipher suite. Will be solved in the next Windows version.

In the above test, I was using
Windows: 2.3.4
Debian: 2.2.12