There is a broad pattern of virtualizing part of a system. By “system” I mean here some suite of objects that have been assembled and connected to perform a task. In order to understand this assemblage we virtualize some natural portion of the assemblage by putting virtualizers around this portion where the traffic can be observed or even transformed. Virtualizers are needed at each point where there is a cap on one side of the membrane to an object on the other side. Virtual machines are a venerable token of the success of this pattern. If eq? is generally available code is in a position to sense this subterfuge and change is behavior which amounts to subverting the virtualization.

My incomplete response is that this pattern is generally (always?) in conjunction with a membrane which separates the larger assemblage into two parts and only those connections that span the membrane need these front-ends. For some component to abuse eq? it would need both the real and virtual versions of a capability. I claim that for each cap X, for which a virtual version Y has been created, and either side of the membrane, that only X or Y but not both will exist on that side of the membrane. This intuition comes from my experience with virtual machines which use this pattern in many variations.

As a backup argument I note that code can be run while denying it access to eq?. While eq? is likely primitive, it is accessed via a capability. I do not recall using this trick but even eq? may be virtualized!

I think that neither argument is very persuasive.