I wonder: Of cases where overload resolution via available instances would be reasonable, how many would also make sense as a closed type class? By comparison, it seems that many uses of OverlappingInstances are really just trying to express a closed type class with one or more default instances, akin to functions with _ patterns. I think, though I'm not certain, that both would be straightforward and non-fragile for a closed type class.
Someone recently described the HASP project, at http://hasp.cs.pdx.edu/. It describes "habit", a haskell like language with some additions and subtractions. There are a couple interesting extensions to 'instance' declarations: -- explicitly declare that there is no instance, halting the compiler's search instance xyz fails -- declares instances along with search order instance abc ... else def The result is that if you put 'fails' at the end, you can make a closed typeclass. Presumably you could also make typeclasses open but only in a restricted way. Also presumably the compiler would then be able to make better decisions about overlapping instances and you could avoid a lot of overlapping problems. Of course, it's just a paper with no compiler, so it's all "presumably" for the moment...