Ah, I see. Artifact dependencies would allow you to build that configuration instead of having to run two cargo builds. You wouldn't be able to publish the package, though, with an unpublished (even if optional) dependency; the rule is that only dev-dependencies can be missing. You'd have to publish with a modified version of the manifest Cargo.toml.
Maybe there could be a separate feature which allows deleting only-for-workspace-development features & dependencies from a package being published.
Another thing: if cargo run built all binaries, this would break the xtask pattern, which relies on cargo xtask being locally aliased to cargo run --package xtask, and the build of the xtask binary itself is supposed to be lightweight (so that you can execute tasks without full rebuilds even if you changed some source)
It “respects” it, but it will not install them, the binary is built into a temp-dir and a path is provided to you allowing you to either execute it as part of your build.rs or embed it into your crate as a static blob.
FWIW I've been using the xtask pattern for a few years, and while it's initially fairly annoying to build your own task runner up front it is quite nice once it's there, and crates like clap and cargo_metadata make things fairly straightforward.
The main problem I've found is that running tests from ides and the like doesn't work great if there's environmental stuff the build is expecting from the task builder. I'm honestly not sure what a cargo native build should do in those situations, so I'm not really salty about it.
Basically, IDE runs cargo test, that internally proxies through your own runner (which may be the same xtrask binary), and that could setup env and whatnot. Probably at some point you'll need to use an env-var to break the cycle and disable the runner.
The xtask pattern looks interesting, and would help with cargo run + cargo build, but not cargo install I think. Wouldn't it be better to have an integrated way to do this with cargo, by extending either default-members or artifact dependencies?
But, the artifact deps RFC linked by @kornel explicitly says this is not a goal (as @Nemo157 also pointed out):
Note that cargo only supplies these dependencies when building your crate. If your program or library requires artifacts at runtime, you will still need to handle that yourself by some other means. Runtime requirements for installed crates are out of scope for this change.
So AFAICT there are two possibilities. And as stated, we're willing to put in the work to implement and stabilize either of these...
my original proposal of extending default-members (would be faster to stabilize?)
extending the scope of artifact dependencies (seems like the better tool for the job?)