I think there can be a certain amount of overlap between different working groups; it’s mostly a question of what their focus is.
It sounds to me that embedded is mostly focusing on, well, embedded systems, which are generally #[no_std] and don’t really want much of std, need to deal directly with hardware, etc.
Portability has a broader focus, including desktop and server style systems that you do want to port std to, but may only be able to support a subset, or want to be able to do it incrementally and not have to maintain a fork of rustc while doing so. Or ones for which there is no libc, so the C compatibility types like CString are not really relevant. Or wasm.
I think part of the reason that xargo showed up in the embedded world first is that you need to easily be able to set up cross-compilation targets in the embedded world, while for porting to other full-fledged systems someone only needs to do it once to bootstrap the compiler and then it can be self-hosted from then on. Though of course, for systems which haven’t yet had the compiler bootstrapped and binaries available, xargo would help out there a lot in the meantime.
Anyhow, there is work going on for integrating xargo into cargo being led by @japaric .
