Consider using a composition based encoding for some type classes to avoid implicit collisions

We've already adopted this pattern for a few of our type classes to avoid the well known problem that inheritance based type classes bring. All of cats-mtl, as well as Representable, Parallel and NonEmptyParallel already make use of this encoding and can therefore be safely used with the other more canon type classes.

If we look closely at the cats typeclass diagram, we can see which of our type classes could potentially benefit and the important ones seem to be Traverse, CoflatMap and Distributive, which all extend Functor. Another candidate could be Alternative, which one might want to use together with Monad, though I think it's less of a problem, since you can just require MonoidK instead.
And even less urgent, Monad currently has 3 subclasses, Bimonad, MonadError and CommutativeMonad. There could potentially be an issue if you wanted two of those together, but I think it's highly unlikely.

I think we could provide this enhancement without breaking source compatibility and should think about it for our next major version :)

Start by reviewing the existing composition-based encodings in cats-mtl, Representable, Parallel, and NonEmptyParallel, then compare them with the candidates named in the cats typeclass diagram: Traverse, CoflatMap, Distributive, Alternative, and the Monad subclasses. No files or tests are identified; done would require deciding the scope and demonstrating a source-compatible design for the selected type classes.