Perhaps I'm mistaken, but I thought it was rejected on the grounds that it always looked for IEquatable<'T>.Equals first instead of obj.Equals, which has the potential to break any class implementation that doesn't follow the (non-required) .NET guidance for implementing IEquatable<'T>.Equals. That's a far larger breaking change than simply breaking nan comparison.

The only systematical deviation is NaN comparison which may apply to System.Half, and other floating point representations that have a NaN value.

Do you have more examples of IEquatable<`T> deviating from obj.Equals?

I've not seen anyone on the compiler team state that this only affects nan equality. The PR linked says nothing about that, it explicitly states that anyone can make obj.Equals and IEquatable<T>.Equals have different behavior, and this would be a runtime-breaking change for them. Over the course of 13+ years of F# being a supported enterprise product in VS, there is undoubtedly code in the wild that works perfectly today and will be broken silently when there is an updated F# compiler delivered by their tools.

Not saying this means the feature stops, but I've simply not seen "we need preserve the weird nan behavior" as the actual reason for not accepting work like this in the past.

Ok, so hypothetically someone somewhere could be broken. Any examples?

This chat got a bit stale, but @Happypig375 I think you are asking about where obj.Equals can result in different response than IEquatable.Equals.

The simplest example is probably that the default implementation for obj.Equals is often reference equality, which would return false for two different instances of the same object (let's say two persons that are have field name = "Happy Pig"). Using IEquatable.Equals(a, b), this would return true instead.

Another case might be certain time and date instances, perhaps from NodaTime, but I haven't checked, where two instances may be bitwise unequal, but considered equal after resolving, say, the timezone.

However, an argument can be made that if you implement IEquality.Equals that you would want it to behave similar to object.Equals.

In fact, reading more on it in several blog posts and about Microsoft accepting the oddity of nan = nan => false, nan <> nan => true, but forcing the incompatible change for nan.Equals(nan) => true and (nan :> IEquatable<float>).Equals(nan) => true strengthens me in the believe that making this change would be a good thing ™️. :)