Yeah, I was afraid you would run into that - I tested it here and the simple making of a list worked on my example but I guess yours is different. Why this happens is a bit difficult to explain, but I’ll try with my limited knowledge…
The problem is what we call ‘overloads’ on certain RhinoCommon functions. Overloaded functions are designed in such a way as to be able to take multiple types of inputs, and they rely on being able to easily distinguish between the different possible inputs to execute the function correctly. If the functions are written well, this does not cause any problems and adds some flexibility. However, in this case, the functions are badly conceived (IMO), and they get confused - so you get the error message that it doesn’t know how to distinguish between a list of curves and a list of breps. As an aside I think this is a bad way to do things, IMO if this kind of confusion is possible, the functions should be separated into something like BrepFace.SplitWithCurve() and BrepFace.SplitWithBrep() etc… so that there is no more confusion possible.
The solution then is as @Mahdiyar posted above, you specifically need to define your list as a list of curves before sending it to the BrepFace.Split method, so that it knows that these are indeed curves. It’s painful, but that is the current state of affairs.
Edit:
There are several ways to do this, the one posted above, but also something like the following:
from System.Collections.Generic import IEnumerable
#...
splits=brep.Split.Overloads[IEnumerable[Rhino.Geometry.Curve],System.Double]([crv], tol)
Again, I find this positively painful, it would be nice if this kind of problem could be avoided by dis-overloading certain problematic methods.
Edit 2:
I maybe should add that this is perhaps only a problem with python as it is a weakly typed language - other languages may be able to infer the type of objects in the list because the list is created/efined as a list of curves for example… Maybe I didn’t get that right though…