The following works, too:

At least the first part seems to be identical behavior to that described in T6488 for USB devices.

Before you ask: I can write on that device and it works with gpgtar on the commandline:

Was resolved, see T4457

closing, as setting a password on a key without password works (at least in current gpg4win version). For improvement of the user guidance see T6436.

In T6473#170380, @ebo wrote:

And when I set the validity to never expire (works) and afterwards set it to a date again, the date is now only set for the main key

Update: This is as designed, see https://dev.gnupg.org/T6473#170299 point one.

works

works, no KIO error. Gpg4win-4.1.1-beta317

Works. The only drawback is: for the message to be displayed in the "for others" part of the encryption dialog you have to click in the next line before it is displayed.
If you click on sign/encrypt directly, you won't see the warning. At least if you select the recipient by starting to type and the selecting from the dropdown.

And when I set the validity to never expire (works) and afterwards set it to a date again, the date is now only set for the main key

The first testcase (with plain testkey Xena) works, both are extended with "change validity". But the expiry day of the subkey is one day later than the date I gave.

And please add a tooltip for "Certify for everyone to see (exportable)", all other options there have one.
Suggestion for the text:

works

works, Gpg4win-4.1.1-beta295

the option works

in gpg.conf

This works, basically.

works now, Gpg4win-4.1.1-beta295

works

works with Gpg4win-4.1.1-beta295

The workaround works.

I imported only a secret key file generated by "Backup secret key"

works. Including "Verschlüsseln".

See T6474 for the remaining issue.

The simplification works as described except in the following case for importing a private key:

File dialog and notepad now share the last used signature and encryption to self key. Works.

This works if the smartcard with the same private key is not connected, which it usually shouldn't be (outside of testing situations) so that's ok for me.
But I think we should inform the user what is done or isn't.
Currently we get in both cases:

gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                             unverändert: 1
gpg:              gelesene geheime Schlüssel: 1
gpg:            geheime Schlüssel importiert: 1

Which is not very clear in any case but in case the smart card is connected it is in fact wrong, there is no secret key imported, the keystub remains.

Ok, so this is not an issue for a standard user. Still I think "wrong PIN" should be given on the command line, too, and not only in the debugfile output.

works, at least for Yubikeys and Zeitcontrol cards

In Kleopatra an error window comes up in this case:

Kopieren des Schlüssels auf Karte fehlgeschlagen: 
Falsche PIN

works, a key with a revoked uid is accepted as VS-NfD compliant, VS-Desktop-3.1.27.0-beta44

The generate keys etc. actions in the keys part of the view are debatable. At least for VSD I think they should not be shown or greyed out for not VS-NfD compliant cards -> see T6786
(I think there were even algorithms offered for generation on card which would result in an error, but I won't investigate further at the moment.)

I already commented in T5836 which should be discussed here, instead:

The options for key backup+delete, delete and keep all work now, tested with VS-Desktop-3.1.27.0-beta44

Because of the imported certificates tab I mention T6447 and T6183 for the certify question. Closing.

gpg --edit-key; keytocard; save

work as expected.

The reported issue is definitively fixed, didn't test the rest yet

works

works

isn't T3456 the same issue?

my Yubikey works, too, if I disable PIV. With enabled PIV:

Test with GnuPG 2.4.1-beta76 failed with "error getting current key info: invalid name":

The crypto profiles have been removed in Gpg4win 4.1.1