Well that is correct - but every torrent is going to get downloaded at the start. This adds them to the cache. They will then not get evicted from the cache until (1) The cache reaches it's size-limit and (2) this particular torrent's files is the least recently accessed among those in the cache. Assuming that the cache has a decent size, that should do a good job of keeping recent and hot torrents in cache.
Of course the cache works on a file-by-file basis, but you get the point.
They will never get re-cached like this though. Not unless you changed the files are re-wrote them - which you typically won't be doing on torrents. It's not the perfect solution, but I suspect it will will work fairly well anyway. A good enough solution for now - and in later versions we should get more functionality to play with here under the same system.
No, quite the opposite. The data has to go somewhere (or else you'd have to keep a whole torrent in RAM which wouldn't be practical). What happens is that the file is written piece by piece. Each piece is not saved as a file though, but written into different areas of the same file on disk. You can think of it as placing down puzzle-pieces one by one - and when all the pieces are put in the right place it makes a whole file. Before it is completed the file will just be a broken mess.
Correct. The cache backend has a delayed upload feature, and it would accomplish some of the same goals. In my testing I found both the temp-upload and cache-writes functions to be quite buggy though, so I am very hesitant to use these. Just to mention a few - the temp-upload sometimes puts files in the wrong place, and the cache-writes makes the database go nuts and write an inordinate amount of data (re-writing the entire database multiple times a second - continuously). It is unlikely that most of these problems will get fixed now since the main author went MIA a while ago.
Probably just a minor listing-cache thing. It might be solved as easily as just F5'ing the folder, or just waiting a little bit. If not then something in your listing-cache timers are not set right.
The way this works is that as soon as a file enters the cache it is considered by the mount to be "on the mount" and will show up there as if it were part of the cloud-drive. The upload then happens in the background and the cached file can not be removed until it has reached the cloud (except if the program was unexpectedly ended as we talked about earlier). This should ensure that the file remains accessible the whole way though with a seamless hand-over between the systems. Very useful since it can mask the actual upload time, and in theory you shouldn't have to think about anything else after it enters the cache - it should be immediately usable as if it was already done uploading.