The concerns are valid, but
1) adding these (the only possible / most general instances) will not break any existing code
2) cannot break any existing code except that which uses orphan instances (which will always break,so it doesnt matter)
3) brings better consistency, especially since bitraversable has the same instances?
also: i feel like some of the concerns brought up here really are about either
a) more desugaring for Tuples as Sized Lists? aka, i mean Hlist 3 a , when i write the type (a,a,a) ?
//
i've seen bugs in "production" from using the Maybe Monoid in a data aggregation (space leaks are the best!), that doesn't make the Maybe monoid of a semigroup any less useful!
so from my perspective, while yes, some folks use tuples for fixed size homogenuous collections, they are useful powerful tools in the algebra of types and functional programming jiggery pokery! There is no sound reason to cripple our official prepresentative of the the simple polymorphic product type formal, the "*" of our haskell and the eternal dual of the sum of our cases! ;)
strong +1, let the algebras roar :)
to be clear, the arguments against are valid, but i thnk they could be addressed by identifying the changes / tooling that would enable a better fitting of intent. buggy code happens, fix the root, not the symptom