This is something that I'd like to happen.
I think the container-based approach has some obvious advantages and makes sense to pursue. The big downside seems to be portability: you've got to be able to create a container that runs Linux. What's the workflow like for Windows and OS X users? I imagine that, if they can run docker, then they can cross to anything Linux can cross to, but e.g. the Windows->Android and macOS->iOS cases are not served by this design. Is there any hope of doing so? With those cases you also want access to your emulator's GUI, which is probably tricky with containerization.
Distributing the Android NDK / SDK in a container is possibly against the license, so that might require some special case logic.
I've also been intending to add more support for setting up and acquiring cross-compiling tooling to rustup, but I'm tempted to put it in the cargo ecosystem if it can be done nicely, leave rustup purely to dealing with rust binaries.
One of the things that I would prefer is if we didn't have to use a command other than cargo build, and this is one of the reasons to put cross-toolchain management in rustup - it can intercept cargo build.
I have other reasons for wanting to intercept cargo commands as well. I think we should define a rustup-compatible protocol for intercepting toolchain commands, so this kind of tooling can be done within the cargo ecosystem experimentally and not be blocked on upstream. There may be a number of things we want to do wrt tooling that can be accelerated by just making xargo and this tool look like cargo (would we even need std-aware cargo?).
I also am not crazy about the 'dock' name, even if it is intended to be tied strictly to Docker.