.. I'm not trying to say that Haskell 98 only supports global instances, rather I'm saying we should think of it that way and design our libraries with global instances in mind, because otherwise we have serious problems with abstraction.
Thinking of it that way still doesn't make it so. If you want instances to be global, you have to change Haskell 98, by propagating instances through the whole program. Also, you don't mean "global", you mean "at most one per program". The latter matches what Haskell'98 does, but not what Ghc does. The former matches neither, so will lead to trouble in use (just because one user follows your rule, that doesn't mean everyone does, so anytime your user imports a not-invented-here library, his model breaks down).
We agree that this is a failure of the language. You seem to be arguing that we should pretend that the language is not broken in the hope that it gets fixed in the future - I think that's the wrong approach.
I have been arguing that we need to be more precise and explicit about what is going on, so that we can see exactly in what ways the language or its implementations are broken and so that we can avoid errors arising from mismatched implicit interpretations.
(b) giving clients control over which instances they want to use (eg, use set A or set B, or neither) should work, and mostly does, but may run into ghc #2182 and haddock #54. Also, it is advisable only for client applications, not for client libraries, as long as their users might run into unresolved aspect of (a).
I'm not sure what "client libraries" are, but I think I agree, if what you're saying is that orphan instances should be kept out of library APIs. I'd also argue that they shouldn't be used in application code either, but the reasons are less compelling there.
Assuming that LT, LC, and LIa/LIb, are libraries that provide type, class, and two sets of instances, respectively, then using any combination of these libraries that does not include both LIs in an application A is fine, using LT/LC in a library L is fine, but using any LI in another library is likely to cause trouble later (because the LI instances are implicitly re-exported from L, while L's clients might also have other instances for LT/LC's type and class).
Next, I'd like to see whether more control over instance re-export is permissible in theory and -if yes- would like to see it implemented and standardised.
Sure, please do!
Once #2182 is fixed, you will need to implement the basics of this anyway, for ghci sessions (where :m -M should remove access to M's instances), then we just need to provide some syntax for your implementation!-) Claus