As far as I can see, current Travis failure is due to coding style, which could be rewritten. I foresee a real problem however in globbing files that have a backslash in their name.
Do we want to support such filenames?
Should support depend on the filesystem's capability to use backslashes in filenames? (We could guess based on OS name.)
Shall I try and write a glob test for them?

e.g. the Windows command line FTP client uses \ instead of /

Is this really a client issue, or could these backslashes be verbatim user input? Could there be confusion about whether to supply an FTP path or windows path?
What arguments and commands can we feed to a Windows (also, which version?) FTP client to make it send FTP commands with backslashes?

So, after some further testing, the point about blinding replacing the \ character can definitely cause some issues (e.g. UNIX only prevents / and \0 from being in file names, where Windows limits more characters). In my testing with the command line Windows ftp client, even if you specific say cd /my/directory, it translates it to \my\directory.

Is there a way to detect what client is connect and what their OS is? If so, we could just have a shim for specific clients (e.g. if we detect a window client, then do this type of replacement).

I don't have time to test client detection yet, but in case all fails, as a last resort we could make an option for server admins to define an option separator string to append arbitrary options to usernames in the login process. One such login option could state that the client requests backslash conversion for path strings sent by that client in that control session.