For the second, I wonder if newer xlclang++ compiler works with 1.9.

Thank you for the bug report.

Possibly, we can use new GCC option: -ftrivial-auto-var-init=0xFEFEFEFE.
https://gcc.gnu.org/gcc-12/changes.html#uninitialized

The bug was there when it was initially written. It was in 2003, which introduced PC/SC in rG1bcf8ef9dea1: Cleanups, fixes and PC/SC support

The change improve error handling for possible other errors by device: rG53eddf9b9ea0: scd: Fail when no good algorithm attribute.

Pushed the change. Also, it's backported to 1.10 branch.

Thanks for creating this ticket. I'll reply.

Applied to 2.2 branch, too.

I examined all log files you gave us, and I think that scdaemon with PC/SC fails to detect the removal of the USB device.

I've applied the linked patch, but still experience the error. Most of the times, I cannot access my yubikey at all and I am not sure what is blocking it.
I've tried to include as much debugging output as I could below. Please let me know if there is anything else I can do to debug this.

While trying to test the X.509 directory server configuration in Kleopatra, I stumbled over difference between 2.2 and 2.3 and a possible regression in 2.2.

@werner Hmm, okay. So I have tested the wrong thing. To me /etc/gnupg/gpgconf.conf looked very much like a global config file I was supposed to test. I have looked at /etc/gnupg, found the example gpgconf.conf and played around with it. It had some effects (see above), so I assumed that it should work. Since it's obvious from my tests, that it doesn't really work as documented anymore, all corresponding code should be removed entirely (or fixed if it should be kept for backward compatibility).

ikloecker: gpgconf.conf ist not anymore used since we have the global config files.

With /etc/gnupg/gpgconf.conf

[empty lines and comment lines]
*	gpgsm	verbose				[no-change]
	gpgsm	quiet				[no-change]
	gpgsm	debug-level			[no-change]
	gpgsm	log-file			[no-change]
	gpgsm	include-certs			[no-change]
	gpgsm	compliance			[no-change]
	gpgsm	default-key			[no-change]
	gpgsm	encrypt-to			[no-change]
	gpgsm	keyserver			[no-change]
	gpgsm	disable-dirmngr			[no-change]
	gpgsm	auto-issuer-key-retrieve	[no-change]
	gpgsm	p12-charset			[no-change]
	gpgsm	disable-crl-checks		[no-change]
	gpgsm	enable-crl-checks		[no-change]
	gpgsm	disable-trusted-cert-crl-check	[no-change]
	gpgsm	enable-ocsp			[no-change]
	gpgsm	disable-policy-checks		[no-change]
	gpgsm	cipher-algo			[no-change]

all options are correctly flagged as "no change" in the output of gpgconf

More weirdness. With gpgconf (GnuPG) 2.2.34-beta23 I get:

After commenting out the options that gpgconf 2.3 complains about I get:

$ gpgconf --version
gpgconf (GnuPG) 2.3.5-beta17
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I tried to see what gpgconf from master says, but I only get

$gpgconf --list-options gpg
gpgconf: unknown option 'try-secret-key' at '/etc/gnupg/gpgconf.conf', line 95
gpgconf: unknown option 'reader-port' at '/etc/gnupg/gpgconf.conf', line 96

This also doesn't look right:

The following looks very much like a bug.

Example:
/etc/gnupg/gpg.conf:

default-key B81CE112B26A8EA8BE7B95D2E375339BF4C51840

With rG8c878ae4c9dfa9fe26aa15f4f9db3e86833575e9 some rules for allow-mark-trusted were removed from doc/examples/gpgconf.conf, but the comments below which are supposed to explain the example rules still talk about allow-mark-trusted.

Backport done but diligent testing is required.

A clumsy workaround for the Kleo bug is to put "keyserver ldap:///" into the global gpg.conf after an ignore section containing keyserver. This will let gpgconf emit "ldap:///" unless a local gpg.conf exists.

I tried applied the bulk of the patch to 2.2 but w/o reading the key creation time from the card. We don't have the supporting code for latter in 2.2. However this does not make sense. Users should switch to 2.3 if they needs this feature.

Will do.

Fixed for 1.8.8

Backport was done with commit rC1d312bc65846 (for unknown reasons it did not show up in the list of bugs related to this bug; I added it by hand). Fix will go into 1.8.8.

I think that a backport to 1.8. also makes sense