Good! I completely disagree.
Ok. Since we now agree to disagree on the solution, but seem to agree on the problem, if not the language used to describe it (sigh:), it might be useful to note that our suggested approaches are somewhat dual: A every instance should be available as widely as possible B no instance should be available more widely than necessary One consequence of following A is that it doesn't matter whether an imported module exports instances, because anyone possibly affected by them will have them anyway. That is less flexible than B, as A doesn't allow for localised instances, but that limitation is in line with Haskell'98 and means that the only trouble that can arise from conflicting instances is that a program doesn't compile. This means that some code can't be written, because missing instances can't be added to external libraries, which also means that there can't be two libraries providing or using different instances for a shared class/type. One consequence of following B is that very fine control over instance import and export needs to be exercised, with the benefit that localised instances become thinkable (they have been possible in Ghc for some time, but could be put on a less adhoc basis), at the expense of having to think carefully about possible conflicts arising from different libraries providing or using different instances for a shared class/type. This means that the current language limitations become very visible, as they interfere with the fine control of instance re-export, which also means that it is easy to mess up. As for orphan instances, approach A forbids them entirely, while approach B forbids importing them into libraries (in the present context, a library module is a module that can be imported). So, in B, orphan instances can only be imported into applications (modules that aren't themselves imported). If one absolutely needs to combine a library L with some orphan instance module O, one should provide two versions of L, one with and one without importing O. As for language limitations, approach A tends to adapt to them, while approach B tends to highlight them. I hope that summary isn't too biased?-)
instance Functor T where fmap = fmapT
Providing default instance method implementations instead of instances is indeed used in practice, eg Data.Traversable.
Since libraries@ is the maintainer for Control.Applicative, may I suggest to add Control.Applicative.Alt, differing from the original only in omitting the import of Control.Monad.Instances? Then all importers of Control.Applicative should be checked for whether import of Control.Applicative.Alt is sufficient, and be switched to that if possible.
That justs moves the problem around, and doesn't fix it.
While giving up Haskell'98 compatibility, as in your suggestion, cuts the Gordian Knot? I don't think so, but then we tend to disagree on such things;-) Would anyone else like to venture an opinion? Claus