Tools / Refresh OpenPGP certificates runs gpg --refresh-keys. I don't think that this command knows anything about WKD.

Anyway, our plan for Kleopatra is to remove Refresh OpenPGP certificates in favor of Update all certificates which doesn't use gpg --refresh-keys, but the same code we use the updating individual certificates.

I'll remove "Bug Report" and add "Feature Request" because although from a user perspective it might look like a bug it's in fact a missing feature in gpg. Or maybe it's a bug in the manual of Kleopatra if the manual claims that Refresh OpenPGP certificates would also query WKD.

Just as a reminder, knowledge transfer, because this is easily overlooked in testing but at least one customer would have gotten very annoyed if we had ever deployed an "Update all certificates" function which "added" new certificates. Even with the update of a single cert, we had a "funny" issue, like if you had expired certificates from anywhere and not from WKD (which old keyrings have a lot, maybe with many uids). Suddenly an update would pull in new keys which come from WKD but maybe there they all only have one UID. Because for keyservers the identifier was the fingerprint and for WKD the identifier was the userid.
Or even worse, you explicitly threw out the OpenPGP keys from WKD because you wanted to use only S/MIME, then such a function may not search on any OpenPGP Sources.
When I worked at Kleopatra we didn't want such a feature in GnuPG. Our strategy was to update keys when they are used, about to be used or close to expiry. The whole locate-external-key thing.
I think the feature we had to update in the certificate details is good. But i recommend especially keeping the S/MIME / OpenPGP difference in mind. I would also call it "Search updated certificates" with a tooltip that it might also find "new" certificates for the user. And then an option to disable this either for S/MIME or for OpenPGP.

Since x500.bund.de is such a useful S/MIME Server and S/MIME keyrings can be quite large and have a ton of expired keys be careful here. This might create even more bloated keyrings by loading new certificates for anyone who has ever sent a signed mail. While GpgOL already does a --locate-key if the appropiate automation options are used and an expired key is encountered. So for that customer the Certificate rollover (which happens very often in a large organization with this super short S/MIME certs). Is solved because GpgOL searches for an update when the address is entered. And we wanted to similarly update certificates for file encryption when a file is encrypted. That is one reason it has that similar interface of entering a mail address as the recipient. (Does not work too well, I agree).

In the API design of the newkeyresolver code i had some stub code to check for expiry, update certs after some algorithm to catch revocations etc. I just never implemented that. Since then it was said that dirmngr should do the update or that keyboxd should do the update but not each application for itself.

At least in the config for the customer I think of, please hide such an action from the toolbar. :)