Could you please post the output of 'gpg --status-fd 1 --verbose --decrypt "Neues Textdokument.txt.gpg"' here? That would help us to pinpoint the issue.

Just for your understanding, it this output would say "COMPLIANCE 23" anywhere in it, Ingo and me should look at this issue, if it does not that is something for Werner or Gniibe.

gpg: Öffentlicher Schlüssel ist 2B2F1C74FE523D81
[GNUPG:] ENC_TO 2B2F1C74FE523D81 1 0
gpg: AES256.CFB verschlüsselter Sitzungsschlüssel
[GNUPG:] NEED_PASSPHRASE_SYM 9 3 8
gpg: Verschlüsselt mit einem Passwort
gpg: verschlüsselt mit RSA Schlüssel, ID 2B2F1C74FE523D81
[GNUPG:] NO_SECKEY 2B2F1C74FE523D81
[GNUPG:] BEGIN_DECRYPTION
gpg: AES256 verschlüsselte Daten
[GNUPG:] DECRYPTION_INFO 2 9 0
gpg: Ursprünglicher Dateiname=''
[GNUPG:] PLAINTEXT 62 1663253724
[GNUPG:] PLAINTEXT_LENGTH 4
test[GNUPG:] NEWSIG
gpg: Signatur vom 15.09.2022 16:55:24 Mitteleuropäische Sommerzeit
gpg: mittels RSA-Schlüssel 930A7B212C8EC8F1729DA3F5C464074875570823
[GNUPG:] ERRSIG C464074875570823 1 10 00 1663253724 9 930A7B212C8EC8F1729DA3F5C464074875570823
[GNUPG:] NO_PUBKEY C464074875570823
gpg: Signatur kann nicht geprüft werden: Kein öffentlicher Schlüssel
[GNUPG:] DECRYPTION_OKAY
[GNUPG:] GOODMDC
[GNUPG:] END_DECRYPTION

The data from the above output was additionally OpenPGP encrypted to self.
The "not compliant" message only shows when the data is additionally encrypted to a public key.

Does the recipient know the public key that was used for encryption?

In T6205#163303, @ikloecker wrote:

Does the recipient know the public key that was used for encryption?

no

Works as designed. Whether the design is a good choice is a different
question.

When checking the compliance we do this:

for all symmetric encryption packets
     If cipher algo is non-compliant
         return "Non Compliant".

for all public key encryption packets
    if public key is NOT in the local keyring
         return "Non Compliant".
    if public key algo is non-compliant
         return "Non Compliant".

If no key packet at all
    return "Non Compliant".

return "session key is compliant encrypted"

I don't think that this makes a a lot of sense. If for example a
rogue sender or recipients re-encrypts using a non-compliant
algorithm, he could as well leak the plaintext directly without
modifying an extisting message.

My proposal would thus to change the second loop above to

for all public key encryption packets
    if public key is in the local keyring
       and public key algo is non-compliant
         return "Non Compliant".