The test certificates do not have a crlDP, so there is no crl check done and no dirmngr is called for this. (see here)
After repeating the command the issuer is looked up from the dirmngr cache. In this test case the dirmngr is not called for a crl check but for a lookup.

Are those other issues something to look into?

• FAILURE at the end of the second gpgsm cli command output (pinentry dialog for the first recipient is cancelled, second one is entered correctly)

The error comes from this log error message. Cancelling the pin entry leads to Operation cancelled. gpgsm exits with an error if an error was printed with the log_error function.

• The first time the gpgsm cli command is executed (without background processes), dirmngr is not started. The second time it is

This is related to T8333: Kleopatra: S/MIME decryption fails for certs with crl check problems.
In de-vs mode we have to check the certificate chain which is done after we successfully decrypt the session key. Checking the certificate chain includes a CRL check (which is done by the dirmngr).
With 4a8f177f390b270df9a86ea47d8eced85420d7d4, this should only happen if we are actually in de-vs mode.

The trust status lines refer to the certificate chain which has to be checked (for validity and the de-vs flag) in de-vs mode. Thus i think the trust status lines are necessary.
With rG4a8f177f390b the cert chain is now only checked in de-vs compliance mode. (The issue remains for the de-vs mode.)

Thanks for reporting. Should be fixed with rGa19534b70e27: gpg: Fix possible double free in import_revoke_cert..

Test results with the same files as in my last comment and the updated patch:
In cases 2 and 4 where no compression and no --chunk-size was used, and a
later tag was modified the output file still remains.
In all other cases no output file (with or without .part) remains.

I tested following cases with a 100~mb file (GnuPG 2.5.20 on linux):

Tested on Linux with GnuPG 2.5.20.
Testing with a small file (16~byte) did not leave a broken file. If I
understand Werner correctly it is due to libgpg-error/estream.c:
fcancel emptying the buffer if the file fits in the buffer.
Thus I tested with a 1GB file.

$ gpg -o bigfile.encr -z0 --force-ocb -c bigfile.txt

Then I modified bigfile.txt.

$ gpg -o a.out -d bigfile.encr

Output before patch:

gpg: AES256.OCB encrypted session key
gpg: encrypted with 1 passphrase
gpg: gcry_cipher_checktag failed: Checksum error
gpg: problem reading source (1069547542 bytes remaining)
gpg: handle plaintext failed: System error w/o errno
gpg: WARNING: encrypted message has been manipulated!

A broken file remains.

I tested your patch applied to current master 2.5.20.

Yes, I will test the patch. Thank you for the instructions.

Here is my attempt for fixing the de-vs compliance check when verifying a signature:

The gnupg manual (page 113) mentions:

I have been able to reproduce this on linux with gnupg 2.5.14.
I had two users (named Alice and Bob in the example), each generating a key pair.
These are the steps:

• Both users have the "use-keyboxd" option in their common.conf (i could not reproduce the bug without this option)