Functions derived from sequenceA get unsolved type constraints.

[gusty]

If we try to define replicateM for Lists:

let inline replicateM n x = sequenceA (List.replicate n x);;

we get:

error FS0001: A type parameter is missing a constraint 'when (FsControl.Traverse or  ^a Microsoft.FSharp.Collections.list or  ^d) : (static member Traverse :  ^a Microsoft.FSharp.Collections.list * ('?63560 -> '?63560) *  ^d * FsControl.Traverse ->  ^d)'

If we try it for Sequences it works fine.

[gusty]

I did some tests and finally this has nothing to do with the issue of the flexible type as suspected at the beginning.

The problem seems to be that when type inference starts solving constraints for a type which has an implementation in sequenceA, somehow takes the constraints of the Default1 overload.

A good compromise solution is to take out the Default for primitives and add all overloads for primitives, making sure all instances for traverse are explicit at sequenceA. The problem is the overload for seq somehow translate this issue to their subclasses, but if its implementation doesn't rely on traverse, the constraints for traverse are not 'inherited'.

Here's a [test](https://gist.github.com/gmpl/fbffb545b39d35df9245. It seems to work fine and it doesn't prevent to use the fallback mechanism on user defined types.

[gusty]

May be we should apply this principle to all FsControl library. It will increase the amount of code but would simplify the design and as seen here it might reduce the nested-constraint complexity and avoid potential problems like this.