Hi Michael,
(b) having the longer name will allow the unqualified import approach ...
The longer name just reduces the possibility of conflicts, which might be already sufficient and in the case of 'zeroBits' it might be really the right thing. I think the point of proponents of qualified imports is, that by having 'Bits.zero' instead of 'zeroBits' you're typing almost the same amount of characters, but the first solution is safer. I don't think that anybody would like to write 'Bits.zeroBits', sure you could still explicitly import 'zeroBits' and still have the same safety, but then you have more work with the imports, and at the end nobody wants to do more work and this seems to be the common ground of users and non users of qualified imports ;).
But that's only one half of the "package interoperability" issue. I face this first hand on a daily basis with my Stackage maintenance. I spend far more time reporting issues of restrictive upper bounds than I do with broken builds from upstream changes. So I look at this as purely a game of statistics: are you more likely to have code break because version 1.2 of text changes the type of the map function and you didn't have an upper bound, or because two dependencies of yours have *conflicting* versions bounds on a package like aeson[2]? In my experience, the latter occurs far more often than the former.
I mostly came to the conclusion, that the PVP is perfectly fine for binaries/executables, especially in conjunction with a cabal sandbox, but in a lot of cases annoying for libraries. Greetings, Daniel