Let's just pause and consider what is already available on hackage today for these situations:
In my constraints package I have a class named `Lifting`, which provides.
class Lifting p f where
lifting :: p a :- p (f a)
Lifting Eq, Lifting Monad, Lifting Semigroup, Lifting (MonadReader e), etc. are then able to be handled all uniformly.
It is, alas, somewhat annoying to use, as you need to use `\\ lifting` with a scoped type variable signature to get the instance in scope
The currrent Eq1 is a somewhat more powerful claim though, since you can supply the equality for its argument without needing functoriality in f. This is both good and bad. It means you can't just write `instance Eq1 f` and let default methods take over, but it does mean Eq1 f works in more situations if you put in the work or use generics to generate it automatically.
For the rank-2 situation, I also have `Forall` and `ForallF` which provides the ability to talk about the quantified form.
ForallF Eq f is defined by a fancy skolem type family trick and comes with
instF :: forall p f a. ForallF p f :- p (f a)
This covers the rank-2 situation today pretty well, even if you have to use `\\ instF` or what have you to get the instance in scope.
I don't however, have something in a "mainstream" package for that third form mentioned above, the 'Functor'-like form, but I do have classes in semgroupoids for Alt, Plus, etc. covering the particular semigroup/monoid-like cases.
Finally, going very far off the beaten and well-supported path, in `hask`, I have code for talking about entailment in the category of constraints, but like the above two tricks, it requires the user to explicitly bring the instance into scope from an `Eq a |- Eq (f a)` constraint or the like, and the more general form of `|-` lifts into not just Constraint, but k -> Constraint, and combines with Lim functor to provide quantified entailment. This doesn't compromise the thinness of the category of constraints. I'd love to see compiler support for this, eliminating the need for the \\ nonsense above, but it'd be a fair bit of work!