That is already how it's defined in the `base` package right now though:

    class  Eq a  where
        (==), (/=)           :: a -> a -> Bool
        x /= y               = not (x == y)
        x == y               = not (x /= y)

https://www.stackage.org/haddock/lts-18.17/ghc-prim-0.6.1/sr...

The way this works is that when you implement the `Eq` typeclass for a type, you can provide more specific implementations. A minimal complete implementation is to implement either == or /= for your type, and the other definition will apply.

The way this breaks existing code (iiuc) is that as a top-level function, if you have imported the `Eq` type class but haven't imported the `Prelude` module implicitly (on by default but can be turned off), you will not have `/=` in scope anymore.

I think people are upset by this less because of how hard it would be to fix, but more because of how it acts as a sort of signaling change ("they're willing to break my code for this, which I didn't want, but not for X which I did"). The most common value of X I've seen is removing or reworking the partial functions in the Prelude (e.g., head / tail on `[a]` raising an exception instead of returning `Maybe a`).

I had never looked at the definition of Eq. Interesting. How are these operators expanded and evaluated without falling into infinite recursion?

that's a default implementation, however it's not true for every type, hence custom implementations

Right. With the current situation you could define a custom /= for every type. In the new situation /= is a regular function which is defined as `a /= b = not (a == b)` and you wouldn't be able to redefine it.