Although it is a bit of a corner case, I would argue that the following behaviour is buggy:

    assert(findSplit!(reverseArgs!canFind)("078.12.13-4.5", ".-") == tuple("078", ".1", "2.13-4.5"));

To understand why, consider the following more explicit code:

    void main()
    {
        static bool oneOf(dchar a, string b)
        {
            bool r = false;

            foreach(c; b)
            {
                if(c == a)
                {
                    r = true;
                    break;
                }
            }

            writefln(`matching a='%s' b="%s" returns %s`, a, b, r);

            return r;
        }

        auto s = findSplit!oneOf("078.12.13-4.5", ".-");

        writefln("%s %s %s", s[0], s[1], s[2]);
    }

Output:

    matching a='0' b=".-" returns false
    matching a='7' b=".-" returns false
    matching a='8' b=".-" returns false
    matching a='.' b=".-" returns true
    078 .1 2.13-4.5

The findSplit documentation says: "result[1] is the portion of haystack that matches needle". Yet, the only character for which the predicate returned true was '.'. Therefore, that should be the only part of result[1]. The alternative would be to clarify and change the documentation, I guess.

BTW 1: it's not very clear what the predicate arguments are / can be, unless I missed some part of the docs. Apparently, findSplit tries to use both `bool function(dchar, dchar)` and `bool function(dchar, string)`, IIRC.

BTW 2: Any particular reason for binaryReverseArgs to exist, instead of always just using reverseArgs?