This is true of all of Rust! The ‘could not delete temp directory’ problem is likely a bug in std (or a bug in std’s non-existent workarounds for microsoft’s beta compatibility layer!).
Probably the best thing to do is verify that Rust passes its own test suite in this environment (I am certain it does not).
This situation should work fine with the exception that Cargo may sometimes invalidate some state when it detects the toolchain changing. I’m actually not clear on when this happens or what gets deleted. rustup itself depends on shared .cargo working because it shares it with all of its own installed toolchains.
I’m not sure I understand the question. If you are suggesting that the MSI installation should get it’s own .cargo directory, then at least currently the answer is no - that directory is actually expected to be shared by multiple versions of cargo (though I also have some reservations about how reliable this can be). If we continue sharing the .cargo directory it may make sense for cargo to eventually figure out how to keep per-version caches.
rustup is very much designed to enable SxS installation (assuming you mean SxS in the general sense and not an MS-specific sense), but through rustup. It doesn’t make any affordances for rust compilers installed via other mechanisms, but I have vague plans to make it interoperate better over time. I’d suggest that whatever rust you had installed via the msi’s you should uninstall and reinstall with rustup install. Then they will be installed SxS, but all within rustup.
I am still unclear on why you would want to install both from the msi’s and rustup and what you might expect the interactions between them to be.
Thanks for the report.
