I added the burger icon to Gpg4win-master.
So remaining here is to remove the right-click actions when a certification is selected.

A better solution might be to use categories to have that element "this message will be signed / this message will be encrypted" above the edit window. But what I find more important and so much more a high priority is that in cases we have a failure saving the draft info flags an error message should come up. This happened for a customer and in the logs I could see that MAPI returned an error. the button was not toggled in this case but the mail also was not marked for encryption. T7144 is the task for that so I'd suggest to start with that one.

In gpgoladdin:

Changing the icon is unusual and does not match a native look and feel in Outlook where toggle icons are there for a reason, to be toggled or not. This is also the way how Outlooks native encrypt & sign works and Microsoft will probably have thought about this a bit.

Ah, that was what daniel and me actually talked about. So I was a bit dissapointed when I only found the documentation. :)

noticed testing T7128: The Token is very long. Is the serial number not unique? That one is much shorter and therefore better to handle visually

tested with Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41)

All tables should now show the keygrip without spacing.

Recent changes fixed the issue for the x86_64 builds, but I see similar symptoms in the aarch64 build now. Annocheck reports the following failures:

Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: dynamic-tags test because the BTI_PLT flag is missing from the dynamic tags 
Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-dynamic-tags.html
Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: property-note test because properly formatted .note.gnu.property not found (it is needed for branch protection support) 
Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-property-note.html

I do not have aarch64 machine at hand now to investigate this further, but this sounds like orthogonal functionality to the CET on Intel.

In T6966#189067, @ebo wrote:

This is how the upper part of the "New Group" window looks with Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41):

It seems that, deviating from the task description, something else was implemented. And it's not even what Andre suggested in the comments but seemingly something inspired by it.
I do not like it.
I think that the color coding of suitable certificates is a no go for a11y. And it clashes with our color marking in VSD. Which in that case is a convenience only, that info is also available in a column. Instead of a tooltip in this case.

This task only dealt with the lower pane. It added the warning icon and the tool tip "This certificate cannot be used for encryption." For the upper pane see T6722.

Checked in Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41):
Looks ok to me.

Yes, we can phase it out in master which is what Nico is talking about and which uses Qt 6/KF6. Nobody is going to remove KIconLoader from KF5.

Daniel wrote a migration tool which was merged in January (https://invent.kde.org/pim/akonadi/-/merge_requests/154), i.e. a few weeks after he wrote the documentation. He foresaw that the documentation "will go out-of-date quickly". ;-)

This is how the upper part of the "New Group" window looks with Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41):

The basic task is definitively done and looks good.
It is not clear if the improvement wishes commented later have consensus and they should be addressed in an new ticket, anyway.

Tested with Version 3.2.2.2405000+git~ (Gpg4win-4.3.2-beta41)

Btw. Here is a nice backtrace, which I think is similar to the crash part of this Task:

I think the crash in the end is the same we have in T6688: Kleopatra GPGME: Reported assert on exit where quitting kleopatra with running jobs tries to cancel all open contexts and then crashes where the assert would be triggered in debug builds. In T6688 we just hid this issue again by not keeping the deviceinfowatcher running.