Note that this fixed it only for the case that the local trustlist.txt is created via "Trust Root Certificate" in Kleopatra.

changing it back to general gpd5x (done) as the bug was never in any release.

Note that the screenshots from this ticket no longer show the current state, that can be seen here:
https://dev.gnupg.org/T8035#214867

I do not see this in Gpg4win 5.0.2. For me the result is "unknown host" without the beta compliance for one of the certificates, "invalid CRL object" for the other.

As I'd like to have it in vsd34, I'll set that tag (and of course gpd5x, too)

with VS-Desktop-3.3.97.11-Beta (GnuPG 2.2.54-beta9)

Without GpgsmCompatibility set and with the trust in the Root-CA established in the global trustlist file (the local one does not work for vs-complicane without GpgsmCompatibility=de-vs-trustlist , as expected), the compliance of a signature or decryption is now shown correctly and in accordance with the certificate status shown in Kleopatra. If the Root-CA is only trusted locally, the certificate and the signature are shown as "certified" resp. "not-compliant".
In short: everything works as expected if GpgsmCompatibility is not set.

It is also shown in gpd-5.0.2:

with GnuPG-VS-Desktop-3.3.90.9-Beta-Standard gpgsm now never shows the line [GNUPG:] VERIFICATION_COMPLIANCE_MODE 23. Therefore Kleopatra always shows "not VS compliant" now on verification and decryption. Even though the certificate is shown a VS-compliant in the list an when encryping:

Seems I forgot to note that icon removal works when resetting to defaults. And the VSD related Categories are no longer shown in Gpg4win. Tested now with Gpg4win 5.0.2, but I believe it was already ok in 5.0.0.

If Tobias remembered correctly, then https://dev.gnupg.org/T7334#193396 still needs to be implemented.

I've removed the sentence in the German de.po on master.

ok, neither is a no-brainer, i see. But I would vote for the left to right order, i.e. the alternative you mention. This has the advantage that the card type is listed on the left side with which one can maybe better identify the card. In my example the type is "Yubico OpenPGP-v.3.4-card", I do not see the info that it is a Yubikey anywhere else. Therefore a blind user will only get that info up front if the left side is read first.

Your suggestion sounds ok to me, maybe with a slight change for the message: "Failed to encrypt the notepad because at least on certificate could not be validated."

yes, basically it's what we want.

2.2.53 was released wit VSD 3.3.6

I tried but couldn't reproduce it any more. Therefore setting it to invalid.

Before making subtickets for each application: I wonder if it is not all Kleopatra anyway? Isn't the security approval dialog basically Kleopatra?

The equivalent for invalid S/MIME certificates are not-certified *PGP certificates.
(Valid/invalid are not ideal as technical terms as they have a broad general meaning, too. I hope my usage here is correct ;-) It is what I gathered from an explanation given by Werner.)

feedback of @mmontkowski needed

Invalid and expired are different cases.

According to Werner, that should be:

After talking to Werner I lower the prio as apparently there is no direct customer request for this

To clarify, the state in Kleopatra Ingo described a year ago has changed, with T7579: Kleopatra: improve menu items the refresh option in the Tools menu was removed. Both actions to update certificates - in the context menu and in the details - are/work the same.

The remaining open points of this ticket will be "won't fix" for now. When we plan to change something here, we should open new tickets, this one got confusing.

Sound sensible. Ok, then this ticket will only revert T8022 for archives which were renamed.

1. That the users focus on the documentation which is more important for them.
2. That the menu is not too long. This point will be +/- moot now but removing "more documentation" now would make extra work.

And 1) stays valid. So I'd keep it in place until all the new documentation is available. Unless @ikloecker sees this differently

Please keep in mind, that for the 3.4 release, we will most likely only have the User Manual ready, not sure about the Administrator Manual.

added vsd34 for the resetting of the defaults part only

In vsd 3.3.6 the option is now greyed out.