I fully agree with Henning here, and I think we will never ever reach a consensus about these instances. This is caused by the fact that there are 2 contradicting goals here, and which one is more important is a totally personal opinion, not something which can be proved or shown otherwise:

   * Type safety, a.k.a. "if it compiles, it works": We definitely lose on this side with the given instances, and we lose even more when there are more instances.

   * Consistency: If there is a unique way to define an instance, let's do it, and do it for *all* such types. Just like type safety, this is a valuable goal, and one which is reached by Haskell to very large amount.

Personally, I would very much prefer nuking the Functor/... instances for pairs, the resulting length/maximum/... semantics are total nonsense, even if they are consistent. Let's not forget the "principle of least surprise", a very worthy goal, which is heavily damaged by these instances. But the pair instances are already there, and removing them would damage the Haskell ecosystem quite a bit. So what can we do?

   a) Actually nuke the pair instances, accepting the resulting damage and "holes".

   b) Keep the pair instances. But then we should really add the remaining tuple instances, too (consistency!), *and* we should add a compiler flag/pragma for people wanting to avoid them.

So a reluctant +1 for b), but only *after* we have a flag/pragma. A strong -1 for adding the instances before such a flag/pragma.

Next battle: What will be the default for the flag/pragma? >:-)