Thanks a lot for your answer!
However, as much as this connex question is also very much of interest to me as well, I do not believe it to be directly related to this issue at hand.

The instance eq_rel_rewrite does allow extensional rewriting in this context, which actually is what happens in the first Goal (I rewrite R ≡ S in the goal R x y by virtue of the pointwise_relation part of the instance).

The failure is the exact same case, but instantiated with slightly more complex “R” and “S”. The equation F († R) ≡ † (F R) is already in my context, I do not need to derive it.

Oh I see, thanks! This solution is certainly impractical as is, but it helped me understand much better the issue, and how indeed it is related to the other thread.

To be certain though, the problem has to do with the difficulty for the rewrite tactic to parse the goal as the appropriate function application for it to trigger the search for the appropriate pointwise_relation ... instance in the first place. But the rewrite would be valid for any relation, assuming only the existence of one such instance. The smaller, more abstract, example below show cases this I believe.

It intuitively (naively maybe?) feels like the type of EQ should contain enough information to automate this process. I’ll get back to reading the other thread now that the situation is clearer in my mind.

Best,
Yannick

EDIT: What I meant by having intuitively enough information is this dirty piece of Ltac I guess:

@Yannick Found a solution for your reduced example. You’re right, my link is likely not relevant, and your subrelation instance might be a solution to the problem there.

Instead, your problem seems to be with unification — I’m guessing that somewhere, rewrite checks your goal contains an application by unifying ?f ?x against F (G P) x; while solving ?f = F (G P) might seem easy, in general this is an instance of higher-order unification, which is famously undecidable and which Coq approximates.

I’m surprised that your case is a problem, but ssreflect’s rewrite fixes it by using Coq’s new unification algorithm. The fix for the first example takes two lines:

PS: Thanks @Yannick for finding out this trick — it seems to fix my original issue (pending more extensive testing, also for performance) so I plan to contribute this to the library where I run into this. I credited you in the relevant issue:GitLab

Some of you (me included) might have struggled rewriting into f a using H : f ≡ g. Today, a user called [Yannick Zakowski](https://coq.discourse.group/t/confused-with-a-failure-of-a-generalized-rewrite/783?u=blaisorblade) discovered a fix by reading...

Thanks a lot for this ssreflect-based solution! It is a bit frustrating to have these three incomparable rewrite tactics at the moment, but I’ll give a shot at systematizing the use of ssreflect’s implementation in our code base and see what happens.