I share Greg's concerns about polymorphic projections. For example, given a function
sort :: Ord a => ...
we don't allow any 'a' that happens to export a operator that's spelled <= to be passed to 'sort'. We have the user explicitly create an instance and thereby defining that their <= is e.g. a strict weak ordering and thus make sense when used with 'sort'. This explicitness is useful, it communicates the contract of the function to the reader and lets us catch mistakes in a way that automatically polymorphic projections don't.
But the difference is that <= is (potentially) an arbitrary function, so we need to be careful that the instances make sense. A formally correct system would insist that all instances are (at least) reflexive and transitive. But in the case of records, we know what the instances are: they are projection functions. Every single (automatically generated) instance does exactly the same thing: it projects out one component of a record. This isn't like OO polymorphism, where "messages" are actually arbitrary functions which could do anything, the polymorphism is exactly the same as that of fst and snd.
At the very least use two different LANGUAGE pragmas so users can have one without the other.
This I can agree with. It was the way that Greg mentioned it in every single email which was starting to worry me. Barney.