Passing multiple `--target` options behaves differently than compiling separately

[mohe2015]

Problem

Passing multiple --target options fails to compile while running cargo separately works.

Steps

Create an empty lib project with

[package]
name = "cargo-multiple-targets-bug"
version = "0.1.0"
edition = "2024"

[dependencies]
tokio = { version = "1", features = [] }

[target.'cfg(target_arch = "x86_64")'.dependencies]
tokio = { version = "1", features = ["full"] }

Run: cargo build --target wasm32-unknown-unknown --target x86_64-unknown-linux-gnu. It fails with This wasm target is unsupported by mio. If using Tokio, disable the net feature.
Running cargo build --target wasm32-unknown-unknown and cargo build --target x86_64-unknown-linux-gnu separately works.

Possible Solution(s)

No response

Notes

Feature introduced in https://blog.rust-lang.org/2022/09/22/Rust-1.64.0/#cargo-improvements-workspace-inheritance-and-multi-target-builds
Maybe related to #1197 ?
Found this while using rust-analyzer with multiple targets in the config and first thought it was a rust-analyzer specific problem.

Version

cargo 1.90.0 (840b83a10 2025-07-30)
release: 1.90.0
commit-hash: 840b83a10fb0e039a83f4d70ad032892c287570a
commit-date: 2025-07-30
host: x86_64-unknown-linux-gnu
libgit2: 1.9.1 (sys:0.20.2 vendored)
libcurl: 8.14.1-DEV (sys:0.4.82+curl-8.14.1 vendored ssl:OpenSSL/3.5.0)
ssl: OpenSSL 3.5.0 8 Apr 2025
os: NixOS 25.5.0 [64-bit]

[epage]

It looks like features are being unified across targets, even with resolver = "2" which sounds contrary to what is intended with resolver = "2". I am not seeing any discussion of feature unification in #8176 or any linked PR or issue. I'm also not seeing any feature related tests in https://github.com/rust-lang/cargo/blob/master/tests/testsuite/multitarget.rs

[epage]

I worry that fixing this would be a breaking change at this point and we may need a resolver = "4" for this.