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.

After setting compliance for gpg, the operation hangs (seemingly forever) at "C:\Program Files\GnuPG\bin\gpgtar.exe" --utf8-strings --cms --skip-crypto --output - --encrypt -T- --null -- for the the first invalid certificate. After aborting this, the gpgtar process is gone, but the gpgsm process remains.
This should be due to T8187: Kleopatra: File encryption with invalid S/MIME certificate hangs indefinitely. The other certificate again returns the expected "invalid CRL object"

This seems to happen only on Linux where tar is used for creating the archive. If I change pack-command-cms (in libkleopatrarc) to 0|gpgtar --utf8-strings --cms --skip-crypto --output - --encrypt -T- --null -- (which is basically the same as used on Windows) then the problem doesn't occur. Apparently, tar behaves differently than gpgtar.

I'll create a blocking ticket which proposes to use gpgtar also on Linux.

Further tests show that this has nothing to do with tar vs. gpgtar. It turns out that the "Input/output error" does *not* occur if the archive file already exists and Kleopatra asks if the file should be overwritten. Further tests show that this seems to be a timing issue.

The current working hypothesis is:
If tar/gpgtar has finished archiving the input files before gpgsm exits with an error then tar/gpgtar don't "crash" and no "Input/output error" occurs. Otherwise, tar/gpgtar "crash" (according to QProcess) which might actually be a SIGPIPE because the stdout pipe is closed.