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.
Btw. is there any estimate when may the deprecated instances proposal land to GHC?
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?
Years ago, I wrote ban-instance. Should I update it to use Unsatisfiable?
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
According to GHC status, GHC 9.10 is currently scheduled for late March 2024.