How do I reliably tell that two Inspector references point to the same inspector instance?

[continued from Is there a way to tell whether two COM interface references point at the same instance?]

I've got references to Inspector objects from two different sources and need to be able to tell which item from one source corresponds to which item from the other source. However, none of the approaches I have been able to come up with so far worked (reliably):

• I couldn't simply compare the IUnknown interfaces as it seems that the Inspectors.Item() method is returning a reference to a created-on-the-fly proxy object rather than the inspector instance itself. Try it: Accessing the same index twice will return two distinctly different pointers.

• Comparing Inspector.CurrentItem.EntryID is no good either. A new/unsaved items' EntryID is always blank and there could potentially be more than one unsaved item open at a time.

• Inspector.Caption or Inspector.CurrentItem.Subject is likewise ambiguous.

• Temporarily setting Inspector.CurrentItem.Subject (or any other item property really) to an unambiguous value and then looking for that in the other list kind of works but has the annoying side-effect of marking the item in the inspector as "dirty", i.e. upon closing the inspector again the user will be asked to save the item (even if he was just viewing a received mail).

Any other ideas?

Context:

I'm trying to work around the well-known bug/feature that new email messages initiated via Simple MAPI (e.g. Send to>Mail recipient in Explorer context menu) do not generate an Inspectors.NewInspector event thus making it impossible to add any addin functionality to those inspectors (e.g. adding toolbar buttons or executing code on message creation). In my COM-addin I've got an internal list of wrapper objects to catch Inspector-events. Items are added and removed to this list by monitoring the Inspectors.NewInspector and Inspector.Close events.

As an alternative approach I'm using a shell hook: I am now able to get notified whenever a new inspector window is created or destroyed so that appears to be a good spot to jump in and match my internal list of wrapper objects with the Application.Inspectors collection and add or remove new or orphaned wrapper objects accordingly.

I now found that comparing Inspector.CurrentItem.CreationTime was sufficiently reliable for me.