The difference seems to be that "scd devinfo --watch" returns immediately with "Service not active"

There are two things happening at the same time:

1. ReaderStatusThread looks for smart cards by running SCD SERIALNO --all. This fails with "Service not active".
2. DeviceInfoWatcher starts SCD DEVINFO --watch and then polls for results. Polling results in "finished with success". If this happens then DeviceInfoWatcher starts another SCD DEVINFO --watch. This is done because SCD DEVINFO --watch finishes with success when the last smartcard is removed. I have no idea why it exists immediately with success. Could this be related the "service not active" message? If yes, then I guess SCD DEVINFO --watch should probably also fail with "service not active" instead of starting without error and then finishing with success.

Yes, I think the service not active is the cause of the issue. But I don't really understand where this error is lost, I think this should be investigated because I would also expect it not to have a success on this line:
[3900] org.kde.pim.kleopatra: DeviceInfoWatcher::Worker::poll: context finished with Erfolg (code: 0, source: Quelle nicht angegeben)

As mentioned you can reproduce that by using a 2.2 gpg-agent with 2.3 or probably also by building gnupg 2.3 with PC/SCD (although I'm not sure what the configure flag is for this)

Can you please clarify this point: If you run on Unix with --disable-ccid-driver, do you get the same behavior as on Windows?

In T5359#145741, @werner wrote:

Can you please clarify this point: If you run on Unix with --disable-ccid-driver, do you get the same behavior as on Windows?

I'm not sure. I have added disable-ccid to scdaemon.conf, did gpgconf --kill all, and then started Kleopatra. It didn't start an endless loop:

org.kde.pim.kleopatra: DeviceInfoWatcher::Worker::start: Assuan transaction for SCD DEVINFO --watch started
org.kde.pim.kleopatra: DeviceInfoWatcher::Worker::status: DEVINFO_START 
org.kde.pim.kleopatra: DeviceInfoWatcher::Worker::status: DEVINFO_END

And that's all. Inserting a GnuK and pressing reload in Kleopatra didn't make Kleopatra show the GnuK. In scdaemon logged

2021-05-03 09:24:57 scdaemon[7302] DBG: chan_7 <- DEVINFO --watch
2021-05-03 09:24:57 scdaemon[7302] DBG: chan_7 -> S DEVINFO_START
2021-05-03 09:24:57 scdaemon[7302] DBG: chan_7 -> S DEVINFO_END
2021-05-03 09:24:57 scdaemon[7302] pcsc_list_readers failed: unknown PC/SC error code (0x8010002e)

Maybe I'm missing something on my system.

The error code is: No Readers Available. With the latest version you should have seen that string.

Sorry, I have been confused and it took time to understand issues.
Indeed, there are (at least) four issues.

(1) DeviceInfoWatcher expects scdaemon DEVINFO loops forever, watching devices.
(2) DeviceInfoWatcher expects scdaemon DEVINFO detects new device when reloaded.
(3) There is a feature request detecting newly inserted device by scdaemon.
(4) Race between detecting removal and reporting device information.

I didn't understand (1) very well, and the old behavior was DEVINFO returns when no device available.
That must be the cause of trouble.

I pushed the scdaemon change rG48e824b6ea69: scd: Modify DEVINFO behavior to support looping forever. to solve those issues above. Now, DEVINFO keeps looping forever.
Underlying function app_send_devinfo still supports old behavior (loop until no device detected) when it's called with KEEP_LOOPING=-1.

The issue (3) is only solved partially. User needs to "reload" kleo so that scdaemon can scan the devices. It's not yet automatic.