You forget that multiple OpenPGP smart cards might be plugged in. Although it's probably not likely that multiple empty cards are plugged in. (For comparison: The subkey action to move a key to a card allows the user to choose a suitable slot. I think it also offers non-empty slots, but I agree that for the "simple copy" it's better to offer only empty cards to prevent a disaster.)

Regarding the requirements for a key: The action shouldn't be enabled for keys not meeting the requirements. (Just like most other actions are only enabled for a suitable selection of keys.) The info which keys are suitable belongs into the manual and not as wall of text into Kleopatra.

The action shouldn't be enabled for keys not meeting the requirements.

This sounds good.
Will this checks be done on opening the context menu for a private key?

Regarding the smartcards: Should be checked if there is exactly one empty smartcard plugged and don't care about other non empty ones?

The check happens whenever the user selects or deselects one (or more) certificates. All actions that require conditions not met by the selected certificates are disabled. Some conditions are too complex/slow/special to check, e.g. the check if an empty smart card is inserted should happen when the user triggered the action.

Regarding the smartcards: Should be checked if there is exactly one empty smartcard plugged and don't care about other non empty ones?

If multiple empty OpenPGP cards are plugged in then I would simply take the first that's found. Obviously, the dialog should tell the user which smart card will be written to.

The key should be displayed as in most dialogs with the summary. Nobody knows their key by the fingerprint and the user ID is often ambiguous if one has multiple keys.

With Ingo's suggestions it could look like this.

Smartcard error case:

== Simple transfer of an OpenPGP key to a smartcard ==

/\ An automatic transfer is not possible.                    {this /\ is an alert symbol}

- No smartcard was recognized.                               {Only one of these messages will apply.}
- No smartcard with empty OpenPGP slots was found.

[OK]

Normal case:

== Simple transfer of an OpenPGP key to a smartcard ==

Your selected Key:  {key summary}
Selected SmartCard: {smarcard summary}

To proceed choose one of the following options:
( ) Delete key from disk.
    ( ) Make a backup of the secret key to file.  
    ( ) Make a print backup. (Paperkey)
    ( ) I already have a backup of the secret key.
( ) Keep key on disk.

[Apply]    [Cancel]

I think it needs to be made more clear that the proposed options refer to what to do after (!) copying the secret key to the smart card, e.g.

( ) Delete the secret key from disk after copying it to the smart card.
    ( ) Make a backup of the secret key to file before deleting it.  
    ( ) Make a print backup (Paperkey) before deleting the secret key.
    ( ) I already have a backup of the secret key.
( ) Keep the secret key on disk after copying it to the smart card.

I briefly considered something like

After copying the secret key to the smart card
( ) ...

but such a sentence puzzle makes correct translation much harder or even impossible.

A patch to make sure that certificates with ADSKs can be copied to cards: https://invent.kde.org/pim/kleopatra/-/merge_requests/265

Tested with version 4.0.0.250370 (Gpg4win-5.0.0-beta125)
and Yubikey:

Key not empty OR no smart card connected:

Key empty:

Tested ok with keep key on disk:

I looked with alexk at the suggestion from ikloecker https://dev.gnupg.org/T7091#185587
We would modify it a bit to:

( ) Delete the secret key from disk after copying it to the smart card.
    ( ) Make a backup of the secret key to a file first.
    ( ) Make a printed backup (Paperkey) of the secret key first.  
    ( ) I already have a backup of the secret key.
( ) Keep the secret key on disk after copying it to the smart card.

We have to talk about the workflows in the different variations. This needs to be simplified further.

For option one: 5 pinentry windows for passwords or PINs and another misleading "do you really want to delete" at the end although a backup was made. (In this case with 1x cancel and 1x wrong PIN in between 3 backup files in total.)

Option 2: 6 pinentry windows, also the misleading "do you really want to delete?" at the end although the backup was made. In this case with file dialog (other than in option 1)

Option 3: 5 pinentry windows. And in this case the "do you really want to delete?" question at the end makes more sense

So basically it works but we should talk at our next meeting about improvements.