https://danluu.com/file-consistency/ http://danluu.com/filesystem-errors/
I thought the whole point of an encrypting filesystem was that applications using it would not need to care about such things? Unless you're going below the FS abstraction and actually accessing blocks of the device directly, it shouldn't matter.
For a system like Dropbox, which automatically renames files to things like "file.txt (userbinator's conflicted copy 2018-12-25)", this is a problem. For eCryptFS, whose limit is "we typically recommend you limit your filenames to ~140 characters", (https://unix.stackexchange.com/a/32834), the uncertainty is a problem too.
Dropbox could make this work (and did in the past), but they decided it would be more reliable to say they won't try and won't make promises about their client working 100% of the time on these filesystems. (And I guess their support or business department was not thrilled with the option of "we'll let you try but we won't support you even though you're paying".)