I did not think that this is the usecase that wasm was intended for, but I could be wrong.
So, this is just technically incorrect, for a few reasons, but it's not too important to get into (and somewhat off topic.)
With regard to incremental compilation, this in particular is what I'm most perplexed by. I assumed that incremental compilation would be using llvm bitcode for the various crate dependencies of a rust library/executable, etc. This glob of ir would then be submitted to llvm for whole program optimization and importantly, potential inlining.
But If i'm understanding correctly, it sounds like you are proposing that each dependency be compiled separately into a wasm module (which is then out of scope for further LLVM optimizations and inlining); and then finally these are all submitted to the wasm "linker", which simply coalesces and dedups all these functions and symbols into a single binary (which again, I don't think will be hard at all).
This in particular seems like precisely not the usecase that wasm was designed for, namely, that all major optimizations are performed, and then the simple wasm instructions are dumped into a final, complete module. By outputting wasm modules per crate, and then "linking" them, this seems to obstruct important inlining and whole program optimization opportunities that would otherwise have been present.
However, my unfamiliarity with low level details of rust compilation might belie all of the above; I dunno.
Lastly, I can't seem to find anything on LLVM mailing lists, phabricator, or elsewhere that LLD is planning on adding a wasm backend. All I could find is this phabricator issue adding LLVM support for wasm (to emit wasm binaries, which is all that should be required): https://reviews.llvm.org/D31099
Are you sure this is on the roadmap for lld (it probably is, it's just weird I can't find anything)?