My problem with having multiple such typeclasses is that it can increase type signature constraints (at least until type-class aliases are available). Furthermore, no one API will be able to cover everything…

Finally, what does fold over non-empty containers look like? And is such a list really used or are you just trying to come up with possible counter-examples?

I think a better approach to the Container class is to break it up so it’s less monolithic. The functions “empty” and “null” should be in one class (or possibly two), “size” should be in a “Sizeable” class, etc. Then you can define type classes for different families of containers that call in the appropriate class constraints, e.g. Container would require Emptyable and Sizeable, NonEmptyContainer wouldn’t require Emptyable, and so on. I think this would be more usable. Contexts would still be very short because low-level functions would only require the one or two of these that they really need, and most client code would use Container, etc. and pull in all the constraints that way. In this vein I think Monoid should be avoided entirely.

In particular, this will allow support for container types that cannot be empty, such as

data SafeList a = SLast a | SCons a (SafeList a)

One problem with previous attempts at solving this issue is the one-size-fits-all approach a monolithic container class requires. IMO, breaking up the restrictions into small chunks will be more flexible and more usable.