I've attempted to get this working, but it looks like upstream LLVM and Clang don't support musl and Alpine Linux without certain patches that are currenly applied by Alpine maintainers. I personally think that these patches should be merged upstream and then propagated to the Apple's Swift LLVM branches, which would simplify a lot of porting efforts. After that, there's a question whether we need to create a separate Musl Swift module in addition to the available Glibc module to indicate the difference in behavior of those libraries. In that case, this will require Swift developers to replace (or make conditional) import Glibc with import Musl if those are present in their source code. We also need to make sure that the Swift compiler, runtime, ICU and Foundation work well with musl by setting up CI with relevant test suites enabled. All of that is a substantial amount of effort, and I don't think I'll be able to pull it off myself anytime soon, given the amount of other projects I'm currently working on.
@Tof if you're concerned with size, this distroless option described above is something you should try. If your Docker images aren't small enough with distroless, they are unlikely to become much smaller with Alpine. If you're concerned with the amount of space that Swift binaries and libraries that you link with take, you should also consider static linking and then applying WMO/LTO on top of that. There may still be some unused code in the resulting binary, but there's ongoing work on making LTO more effective with the latest update on that avialable here: "[GSoC] LTO support progress report".
I personally would focus my efforts on getting improved LTO into Swift, since that would benefit all platforms in terms of resulting binary size, not just Linux. Only after all those efforts combined with distroless don't lead to good results, I'd continue the work on making LLVM/Clang/Swift work well with musl/Alpine.