I raised the issue mostly to remind everyone that it still existed and that the status quo is quite awkward. I was going to let this rest, but as it seems to still be stirring up a passionate response, I felt it necessary to reply again.
I do strongly believe that bringing Foldable and Traversable into the Prelude and replacing the monomorphic variants would actually be a fairly painless change.
During the transition some people would be forced to manage explicit import lists for their packages. We've paid for this with 'catch', the 'Num' transition, 'Bits', etc. and we're pretty good at managing this sort of change by now.
Type inference has been raised as a factor, but I respectfully disagree that is is a problem in practice with (the bulk of) this proposal. A case may definitely be made that perhaps a few of the combinators, e.g. concat and concatMap should remain monomorphic, but by and large I feel it would dramatically reduce import confusion to only have base only contain one version of each combinator that it exports.
The combinators in Data.Foldable and Data.Traversable simply subsume all of the other redundant versions of them that occur in base.
Sure there are reasons why other libraries have chosen to replicate large portions of the API from Base for particular data types with particular constraints, but those are just that -- other libraries.
Moreover, if Applicative can ever be made a superclass of Monad, half of the combinators in can Data.Traversable melt away and so can several of the ones in Data.Foldable, reducing the footprint further.
I tend to disagree with Ian that mapM, etc. should simply be removed from the Prelude completely. Foldable and Traversable -- unlike almost everything being debated to death in the base split -- aren't things that require heavy machinery. There are no exceptions in them, nothing that is difficult to implement across platforms or compilers. The sum total of language support for them is the DeriveFoldable and DeriveTraversable extensions. They are also quite ingrained in the 'culture' of Haskell.
I for one would hate to lose them from the vocabulary of the Prelude.
-Edward