This way, we have the ability to disambiguate methods from manifolds.

I'm not sure this was what we specifically agreed! :

arclength(method, manifold, geom)

Two traits is a bit confusing and ambiguous for users, another option is that keyword arguments could be preffered and dispatch to traits could be on _arclength, or just one trait would be allowed as the first argument.

There is a point where combinatorial positional traits becomes confusing to read. I'm not sure if two is too many but three definately would be!

Hmm, we could do

arclength(geom; manifold, method)
arclength(manifold, geom; method)

and then dispatch is done internally? I'm still not sure I like the underscore architecture though, it seems a bit fishy for extendability...

Definitely agree on combinatorial position traits being bad. But dispatching off keyword arguments is probably bad form.

I had also considered making algorithms an optional part of this informal "operation interface". But the problem is that you can't shoehorn e.g GEOS() into that framework, so there has to be some form of space for algorithms.

Ok right underscore methods are not so good in an interface. It would have to be something else. So I guess its preferable to have those positional methods as long as we have the keyword methods as the main things in the docs.