Multi-target crates refer to projects where different parts are compiled for different targets, rather than all being built for a single target. Examples include embedded libraries (like Embassy) and web projects with a split architecture—using wasm32 for the front-end and the host target for the back-end.
Currently, there doesn’t seem to be an effective way to use Cargo Workspace for these kinds of projects. It appears that such projects typically avoid using Cargo Workspace.
I'm currently using a workspace for such a project. The main issue I've seen so far is with everything assuming I want feature unification across the entire workspace (solved by adding -p package-name to everything where that's an issue, see 3692-feature-unification - The Rust RFC Book).
It might get a bit more difficult if you actually need two different versions of the same crate depending on the target (Cargo.lock), but that sounds rare.
Are there other issues?
Personally I still find it useful to have them in a workspace, as it makes specifying path dependencies and keeping dependencies at the same version within the workspace easier.
The in-progress solution, for being able to build a workspace and get crates built for different targets as a result, is per-package-target. I haven't used it myself, but apparently it has bugs, so if you are interested in getting this feature stabilized, the thing to do would be to work on these bugs.
Agreed, it would be good to list out the concerns with it so they can be explored.
btw https://github.com/rust-lang/rfcs/pull/3759 may improve some of the behavior.