One small question: this documentation page says:
Standard - file names can’t be as long (~143 characters)
Obfuscation - file names can be longer than standard encryption
Is it referring to the original names of the files or the names of the generated encrypted files?
“File names” including the full path or just the file name itself?
Original names
Excluding path.
However all those things vary from provider to provider! For instance google drive file names can be 8k long I think, whereas the total length of the path must be < 1k for S3. So take those numbers with a pinch of salt.
If you want to find out what your remote can support, try the undocumented debug command rclone info remote:test_directory
Thank you for the clarifications!
Very interesting command! 
But I think I didn’t understand the implications of some of the results:
2018/03/28 17:53:06 EME operates on 1 to 128 block-cipher blocks, you passed 513
2018/03/28 17:53:06 EME operates on 1 to 128 block-cipher blocks, you passed 257
2018/03/28 17:53:06 EME operates on 1 to 128 block-cipher blocks, you passed 129
EME ? “I” (Rclone) passed?
canWriteUnnormalized = true
canReadUnnormalized = true
canReadRenormalized = false
In this case, what does Unnormalized and Renormalized mean?
And yes, it confirmed:
maxFileLength = 143
That is an internal error from the crypt’s name encryption when rclone tries really long filenames.
That is to do with UTF-8 characters. If you write the symbol for é there are two (at least) ways of writing it. The combined symbol or an e followed by an accute accent modifier. These look the same but are different! Some backends recognise this and some don’t. rclone doesn’t use this information yet though, I have some future ideas for it!
Got it, but is there any problem with the related files (with long names)?
No, everything is working fine up to the 143 char limit.
Does Rclone upload the original filenames when the file name is more than 143 chars? or it throws error and not upload?
It should throw an IO error to the OS.
EDIT: For reference, same test on Gdrive
stringNeedsEscaping = []rune{
'/', '5', '8', '9', 'A', 'C', 'Z', '\a', '\b', '\f', '\n', '\r', '\t', '\u007f', '\v', '\x00', '\x01', '\x02', '\x03', '\x04', '\x05', '\x06', '\x0e', '\x0f', '\x10', '\x11', '\x12', '\x13', '\x14', '\x15', '\x16', '\x17', '\x18', '\x19', '\x1a', '\x1b', '\x1c', '\x1d', '\x1e', '\x1f', ']', 'o', 'p', 's', 'u'
}
maxFileLength = 7722
canWriteUnnormalized = true
canReadUnnormalized = true
canReadRenormalized = false
canStream = true
So from what you say @ncw, pathnames on Gdrive are basically unlimited? (8K). The only real limitation is 143 chars on the actual filename (or leafname as I learned from you).
If so I've been misunderstanding. I've been trying to keep my directories short because I thought the limit was on the while path+leafname combined. If you can confirm, because if so I can stop worrying about it and using some longer and more clarifying names 
On gdrive both directories names and file names can be 8k and there is no limit on how deep a path can go.
Yes use as long names as you like on drive!
Huh, weird. Because I'm sure I've seen IO errors resulting from long filenames.
This is with crypt though, but if you have 8k to work with then the extra length added by crypt can't matter much?..
It should be pretty much irrelevant I think
Ok, thanks for the clarification. I will have to experiment a little and see if I can reproduce the issue under more controled cicumstances then, because according to your info it should be basically impossible to run out of characters for Gdrive.