Thanks for the write-up.
Should new code stop using TypeError, in favour of the new Unsatisfiable?
Yes, Unsatisfiable has more predictable behaviour apparently. Now, it’s only warm out of the oven, let’s see how it reacts to people’s usecases.
Also keep in mind that if you need to support GHC versions before 9.8.1, you need to stick with TypeError, or, assuming you’re OK with that, make a dirty compatibility shim with CPP.
I suspect a compatibility shim will be quite hard because Unsatisfiable was introduced due to ergonomics problems with TypeError. I can’t imagine it’s possible to extract any better behaviour from the intersection of the features than from TypeError itself.
The linked issue was closed 4 days ago, so I think it will be in 9.10. That might take another 6-10 months perhaps?
That might be a case where a shim would work well. You could use Unsatisfiable on GHC >= 9.8, and therefore stub out the type class methods in a way that doesn’t work for TypeError.
Probably yes, for the >=9.8 range