The different results are:
* FlexibleContexts approach: `(Eq (Maybe (f a)), Eq [f a])`
* Eq1 typeclass: `(Eq1 f, Eq a)`
* Quantified Constraints: `(forall x. Eq x => Eq (f x), Eq a)`

So if (per my plan[1]) `Eq1` has the quantified constraints super-class,than Andrew Martin's second two options will imply the first one. So it seems that the FlexibleContexts choice --- asking for precisely what is needed --- is the best option, dare I say a principle type.

I think we should pre address any maturity issues or composition/ generality concerns before folding quantified constraint  instances into base

I am with you Carter, but the only issues with quantified constraints we've discussed is around (~) and Coercible, but both shouldn't apply here, so I think that's a red-herring.

In particular, only the *1 classes would have a *wanted* quantified constraint via super class (so just one imposed on instances). Everything else would just use FlexibleContexts or stay the same. [Extra given constraints do not in and of themselves pose inference problems.]

It is because the *1 classes do not involve (~) or Coercible, or have anything like a `Type -> Constraint` parameters that could be substituted for (partially applied) (~) or Coercible, that those concerns shouldn't apply.

John

[1]: So nobody need waste their time looking it up, the super class is (forall x. Eq x => Eq (f x)) => Eq1 f