Personally, I think that I really want to see something slightly different. I would like to see the content in the resource dir to be thinned.
The current approach really doesn't work very well for Linux to be honest. What exactly does the Linux OS mean? Does it mean Ubuntu? Well, that is alright, but that certainly doesn't work on my Linux distribution - exherbo. Android gets away with this because it has specially suffixed everything to deal with this conflict (clang and LLVM treat android as an environment to Linux, similar to how Apple is starting to treat the iOS simulator).
I think that Xcode has a wonderful layout strategy that scales amazingly well. I think that we can easily replicate that across the platforms, and this would only be jarring on Windows, where I think that even Microsoft is trying to move to this model [1], with a slight difference in names. Consider the following layout:
Developer/Toolchains/<vendor>[-...]-<version>/usr/bin/...
Platforms/ubuntu-arm-14.04/usr/lib/...
Platforms/ubuntu-x86_64-18.04/usr/lib/...
Platforms/exherbo/usr/aarch64-unknown-linux-gnu/lib/...
Platforms/exherbo/usr/x86_64-pc-linux-gnu/lib/...
Platforms/exherbo/usr/ia64-unknown-linux-gnu/lib/...
This allows us to have multiple simultaneous toolchains co-installed and switch across versions easily. Additionally, it allows you have the multiple variants of Linux be handled cleanly and have the different versions of the libraries be separated. The top level directory names can be renamed of course. Since exherbo has a co-installed environment, we can flatten the structure there as an example. The exherbo "SDK" would give you the traditional sysroot, while on Ubuntu, the top level directory can separate the architectures and be versioned.
Note that if you really want the traditional layout for a single installation, it is just replacing the top of the tree, and you are done, since the toolchain layout is the traditional unix layout. You merge that with the SDK and you get the normal Linux layout. So, really, it is just replacing the root in the image, which seems perfectly reasonable. The toolchain can be relocated to /opt or /usr/local if they so desire.
This also means that we can easily cross-compile to and from the environments.
Also note, I would include the C++ runtime builds even for Windows, as I have already ported libc++ to Windows replete with MS ABI and all. It is effectively a drop in (source level) replacement for Microsoft's C++ runtime without any additional dependencies.
[1] Side-by-side minor version MSVC toolsets in Visual Studio 2017 - C++ Team Blog