Query on MAPITable fails when there are multiple Office365 accounts in an Outlook profile

I'm trying to locate an address book entry associated with a mail-enabled public folder via its PR_PF_PROXY property from inside an Outlook addin. For this purpose I follow the following steps, using the Redemption library:

1. get RDOStore via RDOSession.GetRDOObjectFromOutlookObject() (passing in the MAPIFolder.Store from the Public Folder in question)
2. get RDOExchangeAccount from RDOStore.StoreAccount
3. get RDOAddressList from RDOExchangeAccount.GAL

4. lookup address entry by PR_EMS_AB_OBJECT_GUID (previously obtained from the folder's PR_PF_PROXY property) via the following query (Delphi syntax):

   RDOAddressList.AddressEntries.MAPITable.ExecSQL(Format('SELECT EntryID FROM Folder WHERE "http://schemas.microsoft.com/mapi/proptag/0x8C6D0102" = ''%s''', [AObjectGUID]));
   

This works fine for about 99% of the cases where there is a PR_PF_PROXY property to begin with (i.e. all newer Exchange Servers). However, I've now got two reports from customers where this isn't working: The query either returns no records or raises an exception (0x80004005: "Error in IMAPTable.QueryRows: MAPI_E_CALL_FAILED"). It's not yet clear what decides which of the two outcomes I get: It does seem to be consistent per folder, though.

So far I haven't really been able to figure out why this is happening in the first place. The deciding factor for reproducing the issue appears to be the presence of more than one distinct Office 365 account in the Outlook profile ("distinct" in that they are associated with different organisations, i.e. different Exchange Servers and thus different PF stores - the issue does not occur if there are multiple accounts connected to the same O365-organisation or if only one account has an associated PF store). If all additional O365-accounts are removed from the profile, the query starts working again - i.e. the associated addressbook entry definitely does exist and has that OBJECT_GUID - I also verfied this via OutlookSpy.

Any ideas?

Are there maybe other, more reliable ways to determine a mail-enabled Public Folder's addressbook entry in the GAL?

P.S.: Just in case this makes a difference: The customers in question are running the 64bit version of Outlook 2016 and the addin is a COM-addin compiled with Delphi 10.1 . I'm also already using Redemption 5.21 (though the problem was first observed when it was still 5.19).