Collections that implement IEquatable<T> should be allowed to be compared with Assert.AreEqual

[RobSwDev]

If I have an interface ISelf that implements IList<T> and also IEquatable<ISelf>, then it is perfectly reasonable to call Assert.AreEqual(iself1, iself2).

At the moment, we have to disable MSTEST0065 due to all the false positives.

[Evangelink]

There isn't really a "correct" direction here, so it's worth being explicit about why.

The fundamental problem is that the analyzer cannot read intent. Assert.AreEqual(a, b) on a type that is both a collection and IEquatable<T> is genuinely ambiguous — did you want the type's own equality, or element-wise content comparison? No static analysis resolves that. So the design question isn't "how do we detect what the dev meant" (impossible), it's "which way do we err when we can't tell, and what does each mistake cost?"

That gives two failure modes:

• False positive (fire when you meant collection equality): the current behavior. The cost is high — as this issue shows, it pushes people to disable the entire rule, so you lose the footgun protection everywhere.
• False negative (stay silent when you meant content): the cost is a missed suggestion on a type that already has an intentional, non-reference Equals — you still get some defined semantics, not the reference-equality trap the rule exists to catch.

For a default-on Warning, false positives are the more expensive error, because a noisy warning gets suppressed wholesale rather than case-by-case. And notably, when a type implements IEquatable<self> (or overrides object.Equals), the rule's own rationale — "for collection-like types this relies on the type's own equality semantics instead of comparing sequence elements" — no longer describes a footgun: the author deliberately opted into that equality. That's the strongest static signal we have that we're out of accidental-reference-equality territory.

So the plan is to narrow, not disable: MSTEST0065 will stop reporting when the compared type provides its own equality (implements IEquatable<itself> or overrides object.Equals). Plain List<T>/arrays and other IEnumerable<T> types that don't define equality — the unambiguous footgun — will still fire.

One known, accepted piece of slippage: types like ImmutableArray<T> implement IEquatable<T> but compare by the underlying array reference rather than content, so they'll no longer be flagged even though element-wise is usually what you'd want. There's no static way to tell "IEquatable meaning content" from "IEquatable meaning identity," and trying to chase it just reintroduces intent-guessing — so we're treating that as acceptable rather than solvable.