This one made me curious because updating the should be UI solved, and it is incredibly dangerous to mess with that. It is super easy to get random crashes when you invalidate the UI too much. It took me ages to get that "stable enough". But also technically an appointment request is a mail. And thanks to dan (afair), KMail can sign and encrypt invitations. And at least for signed invitations they are displayed as appointment so I looked into this a bit out of curiousity.

And I can access the IMAPISecureMessage Interface and the OOM Object IMeetingItem is derived from IMailItem

So technically it should be pretty easy to support signed and encrypted appointments in GpgOL, too. I played around with this out of curiosity and of course the direct and regression riskless fix is just to hide the status view (Although this is also curious, the UI is invalidated on selection change and at least the string tip and the supertip did work correctly for the appointment.) As a first commit I will push the code to remove our GpgOL Status thingy for anything but mailitems as I think is requested here and will make most sense to most users as signed and encrypted invitations are very exotic. Also the mail read ribbon already changes when you hit an appointment, so there is no new "visual movement" by hiding the icon. So I think that is the best solution.
But I am already running most of the mail handling code on a signed invitation mail from kmail with just some few lines of code. But I guess the difficulty will be that it looks in the end like an invitation again. That commit also shows that the UI is invalidated since the icon is properly hidden and revealed again. So there is probably a regression in the icon update and status code.

I wanted to update my scratch branch as a source for cherry-picks. Yes sometimes curiosity and the need to fill my head with some other thoughts even makes me work on GpgOL, it was at some point my favourite project. But it seems I have no commit rights anymore. Which I can understand after loosing my mind so hard. No worries. I would have revoked my access, too.

So here are two patches which just fix warnings, because I then come out with zero warnings and both are clearly unproblematic

This is the one that hides the status icon for things other then mailitems

I don't want to throw too many rocks from the peanut gallery, but I would wish you would at least use log_dbg("Y") or log_dbg("N") so that at least the source line is given as context. But I can understand that you don't want to bother. One commit struck me though which might cause or have caused several followup problems:
9124f33b97373105854260e8a43ec5baf0950154

bool
Mail::realyDecryptedSuccessfully () const
{
  return m_decrypt_result.isNull() || m_decrypt_result.error().code()==0;
}


HRESULT get_is_crypto_mail (LPDISPATCH ctrl, VARIANT *result)
{
  MY_MAIL_GETTER

  result->vt = VT_BOOL | VT_BYREF;
  result->pboolVal = mail && ((mail->isSigned () &&!mail->isEncrypted()) || mail->realyDecryptedSuccessfully ()) ?
                          &var_true : &var_false;

  TRACEPOINT;
  return S_OK;
}

I think this function nearly always returns true, because it returns true for unsigned, unencrypted mails, as realyDecryptedSuccessfully exactly does that and that function is evaluated if mail->iSigned() is false. So It also returns true for signed but not encrypted mails. And only when a mail is signed, and encrypted and the decryption result has an error does this evaluate to false. That can't be the intention, and definetely was not the intention of the original code. That might be the reason such issues occured in the first place because it would have never returned true for an appointment request or anything other that is usually unsigned and unencrypted.