Cross quoting as this was spread across different posts:
Yes, but that's not good enough... e.g. those custom implementations will not participate in contains or other standard library algorithms that could benefit from it. People will have to re-implement their own versions of contains, etc, and that's not a small ask.
Different order of checks should not matter (please give an example if it does). It's true that isDefinitelyNotEqual could be implemented differently by different people (e.g. some would choose to compare the first bytes of Data value in addition to "count" check. But so is isDefinitelyEqual- it could also contain a custom logic unrelated to checking if the bits of the underlying references are equal. However the end result due to such differences is not catastrophic - with some implementations there would be more false positives (negatives?) and depending upon the end goal, just more calls to a full blown "isEqual" will follow, slightly affecting the resulting performance.
This should not be a show stopper! We've been through many of those naming choices.