Cargo resolver reports the wrong "missing" feature when the feature set changes

Problem

A dependency used to expose feature A, and in a newer version feature A was removed and feature B was added.

During update (even with --precise), Cargo printed an error saying that feature B was missing, but did not mention feature A. It also excluded both features from the "available features" list:

    Updating crates.io index
error: failed to select a version for `<dep>`.
    ... required by package `<pkg>`
versions that meet the requirements `<version>` are: <version>, ...

package `<pkg>` depends on `<dep>` with feature `<B>` but `<dep>` does not have that feature.
 available features: ...

failed to select a version for `<dep>` which could resolve this conflict

Steps

1. Create crate dep v1.0.0 with feature foo (and no bar), then publish it to a test registry.
2. Create a new crate, app, depending on dep = "^1" with feature foo
3. Publish dep v2.0.0 where feature foo is removed and feature bar is added.
4. In the app crate, run cargo update -p dep --precise 2.0.0. Observe that Cargo reports missing bar, even though the real blocker is foo.
5. Remove foo from the dependency feature list.
6. Re-run the update and confirm resolution succeeds.

Possible Solution(s)

Ideally, when updating a package:

• get the feature list from every version satisfying the new requirement, plus the previously-locked version.
• If the latest version has all the requested features, select it
• If not, but a different version has all the requested features, select it, but print a warning that the crate is being locked to some earlier version because later versions removed some required features (and list those features)
• If none of the candidates have all the requested features, print all features that are listed from at least one of the candidate versions.

But even without changing the behavior that drastically, this could be improved by simply ensuring that all features that cause a candidate version to be rejected are included in the error message. That is, in the above example, the error message should mention both foo and bar, even though bar is actually present in the requested version.

Notes

Unfortunately, I don't have an actual example crate to demonstrate this problem; I encountered it with a crate in a private registry.

Additionally, the consuming crate was in a workspace, though I doubt that would affect this behavior.

Version

cargo 1.95.0 (f2d3ce0bd 2026-03-21)
release: 1.95.0
commit-hash: f2d3ce0bd7f24a49f8f72d9000448f8838c4e850
commit-date: 2026-03-21
host: aarch64-apple-darwin
libgit2: 1.9.2 (sys:0.20.4 vendored)
libcurl: 8.7.1 (sys:0.4.83+curl-8.15.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: Mac OS 26.5.1 [64-bit]

Reproduce the resolver behavior using the test registry and dependency versions described in the issue, then trace the Cargo update and feature-selection diagnostics. Done means the failure reports every feature that causes candidate versions to be rejected, including both foo and bar, with resolution still succeeding after foo is removed.