Information about revocation keys can now be retrieved from a Key object (see T7118).

I don't think this UI makes much sense. From the user's perspective (and from the gpgme API), designated rekovers are not related to certifications at all. Shouldn't we rather just show this as a field in the list of metadata above the tabs in the certificate details dialog?

There could be several designated revokers, and it's a direct key signature.
So it's like a certification, but not linked to a user ID, but to the key.
Therefor it can't be stored in one field.

Alternatively the revokers could be listed in a separate tab in the details dialog.

What's the use case for multiple designated revokers? I don't think we should optimize Kleopatra's UI for something that's in theory possible with the OpenPGP spec, but which in practice will never occur for a productively used key. The standard use case is that the company wants to be able to revoke the keys of their employees, i.e. there will be a single revocation key.

What's the use case for multiple designated revokers?

You might want to have more revokers in an organisation, just as backup, in case the smacrtcard for one key is lost. You personal might want to have more revokers in case your not able to revoke and maybe don't know who of your trusted persons is still able to do so.

Anyway, there are likely not more that two revokers. But in case there are more we have to deal with how to display this. Like this?

Designated revoker 1: foo
[Designated revoker 2: baa]
(there are more revokers, check with gpg on the command line.)

(IMHO this ^ is not a good way to display it.)
And which of more than two revokers are shown?

So isn't it just easier to put the information in a table and don't worry about edge cases.
Additionally it is now easy to add a button add revoker, etc.

To add some (unrepresentative) statistics: My normal keyring contains 552 keys. 5 keys have a single revocation key. 1 key has 3 revocation keys.

My conclusions:
I see no indication that we need UI for showing a large number of revocation keys. In particular, a separate tab would be complete overkill. I think it's sufficient to show the revocation keys similar to the issuer (of S/MIME certificates) as proposed by Tobias in the MR.