The fundamental problem with crypted files are that in order to --track-renames we need to be able to positively ID them as identical. The foolproof and obvious way is to compare hashes, but the problem is that while we have the hash for the encrpyted file, the cloud drive can't possibly know the hash of the real file inside because it obviously doesn't have our private key and the encrypting a file changes it's hash. Comparing your unencrypted file to a crypted one would be meaningless because they wouldn't match even if identical.
This means that --track-renames work fine on unencrypted->unencrypted, or crypted->crypted (with the same crypt key), but with any other combination we either lack hashes to compare on one side or both.
So the best solution is to avoid re-encryption if possible. For example if you set up a local crypt mount (with the same key) and just pull your files through that before you upload then --track-renames will work fine! (since we now have the same resulting hashes to compare on both sides) This is likely the best and most direct workaround for you, and should be fairly convenient too. Just remember to avoid uploading already encrypted files through your existing crypt remote or else you get them double-crypted 
You will probably want to have 2 mounts for uploading. One for your regular use and another with no encryption (meant specifically to handle these pre-encrypted files).
Let me know if I need to elaborate on how to do this and I will do my best to assist.
And if avoiding the issue isn't possible... then it may still be doable, but it will require new code and some careful thinking. If you are interested in delving deeper into this I made a thread on exactly this topic and had a long conversation with NCW about it and how we may go about attempting to develop a feature that would allow you to bypass this restriction.