EDIT: Next, I predict a linux distro will, after having switched to musl, also support llvm/compiler-rt/libunwind/libc++ as base toolchain instead of gcc/libgcc/libstdc++
You're probably right, but I hate that the work free software developers contribute to LLVM & clang will end up being taken proprietary by the likes of Apple. With GCC one knows that the users of one's code will always have the ability to run, read, modify & share that code, rather than having their rights stripped away.
Also, the licenses of neither GCC nor LLVM apply to programs compiled by either project. I don't think that's what you meant by the copyleft sentiment, but the wording of that bit is weird and it's worth clarifying just in case.
[1] http://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolchain....
The BSDs have been used in proprietary software, but the open source projects continue as the centre of development.
The important points are that such a distro will quickly improve the situation of clang and libc++ compatibility across the board and exercise the alternative toolchain a lot more. In fact, there isn't much incompatible code out there, and it's been fixed mostly due to efforts of Debian, FreeBSD and of course Apple and Bitrig and Gentoo. FreeBSD is the leading force behind making lld a viable alternative to binutils ld and so far ThinLTO (which works with binutils, to be clear) is exclusive to llvm, so there's that.
GCC has some platform specific symbols that are really just functions wrapping assembly. Most of this is related to crypto and AESNI (built in x86 AES operations). This breaks some crypto, which breaks some wifi/file system stuff.
XEN driver uses a GCC specific ASM macro for counting NUMA Nodes and CPU cores.
Dynamic compiling within the kernel for say BSD Packet Filtering JIT requires LLVM Compiler-RT have a custom wrapper. Also some libgcc specific header information.