Uses gpgme-2.0.0 with the above mentioned patches. I have seen no problems in my quick tests.

Key Approval dialog used by GpgOL (VSD only) looks good to me on gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10 (compliance mode):

Notes for testing (and maybe documentation update):

• A few features (?) of the old CSR creation have been removed:
  • The different choices offered after CSR creation (e.g. save to file, send to CA, create signing/encryption CSR with same settings, etc.) have been removed; now a file save dialog pops up when the CSR has been generated
  • Custom labels for the RSA key sizes ([CertificateCreationWizard]RSAKeySizeLabels); we use GnuPG's algorithm IDs as labels (items in the drop down box)
  • Custom key type ([CertificateCreationWizard]CMSKeyType); CSR creation supported (and still supports) only RSA as "key type"; by marking the config key as immutable one could force the creation of signing+encryption CSRs which makes little sense for S/MIME and might have been "copied" from OpenPGP key creation where forcing the generation of keys for signing & encryption does make some sense.
  • Specification of the CA's email address ([CertificateCreationWizard]CAEmailAddress); the generated CSRs are now always written to disk; the users will have to create an email themselves

I fixed the problem (which I identified above) in gniibe/t7759 branch. There might be other causes/problems for the particular symptom, so, I don't know the fix resolves the symptom or not.

tooltip suggestion for d, not trusted and expired:
Ask the sender for an updated certificate and when you receive it, follow the procedure to establish trust and certify it.
or:
Ask the sender for an updated certificate. When you receive it, you need to establish trust and certify it.

Similar situation could happen with gpgsm + gpg-agent, when gpg-agent is invoked by gpgsm.
(1) No gpg-agent.
(2) In gpgme, by engine-gpgsm, gpgsm is invoked with --logger.
(3) In gpgsm_keylist, it makes sure gpg-agent is available by GETINFO agent-check, using gpgsm_assuan_simple_command.
(4) In the server side, it tries to connect gpg-agent, invokes gpg-agent, and connect to the agent again.
(5) On Windows, it may takes time to invoke gpg-agent. And it may try to connect multiple times. Each trial may generate debug messages.
(6) When it takes too much time, the debug messages are too much. It may fill the pipe.
(7) And it blocks at log_string in my_libassuan_log_handler.
(8) ... it hangs.

Hypothetical scenario (gpgsm --server + dirmngr):
(0) It may hang when much debug messages are generated by libassuan to the pipe of --logger (diag_cb).
(1) In gpgme, by engine-gpgsm, gpgsm is invoked with --logger.
(2) If it's the case of standard gpgme interactions which uses gpgsm_io_event, no problem. Because the data on diag_cb is consumed well.
(3) In case of gpgsm_encrypt (or other commands), it uses gpgsm_assuan_simple_command which does not consume the data on diag_cb pipe at all.
(4) In particular, in set_recipients, gpgsm_assuan_simple_command is called by the number of recipients.
(5) IIUC, in the server side, dirmngr is used by the call chain of:

• gpgsm_add_to_certlist
• gpgsm_validate_chain...
• gpgsm_dirmngr_isvalid

(6) In gpgsm_dirmngr_isvalid function, libassuan is used as client side, it generates debug messages.
(7) When there are many recipients, the debug message may be big enough to fill the pipe.
(8) When pipe is filled, it blocks by log_string in my_libassuan_log_handler, waiting the data in pipe is consumed.
(9) ... it hangs.

Backported for VSD 3.4

Backported for VSD 3.4

Backported for VSD 3.4

Backported for VSD 3.4

Backported for VSD 3.4

Backported for VSD 3.4

Backported for VSD 3.4

Backported for VSD 3.4