Cargo seems to ignore constraints on target elements completely

[JavaDerg]

Problem

Cargo seems to ignore constraints on target elements completely.
I'm not quite sure how to describe it else.

I ran into this issue while tying to include bevy and wasmer in the same project.
Cargo would complain about a dependency conflict as syn was pinned to a specific version by bevy. (https://github.com/bevyengine/bevy/blob/db55bf550423e741c3362a2ad33f4fea8bcb318c/Cargo.toml#L82)
This is the only instance of that version in the project I could find, so I made this test project bellow which yields the same result:

[package]
name = "example"
version = "0.1.0"
edition = "2021"

[dependencies]
syn = "1.0"

[target.'cfg(target_arch = "wasm32")'.dependencies]
syn = "=1.0.65"

[target.'cfg(target_arch = "x86_64")'.dependencies]
syn = "=1.0.81"

$ cargo run
    Updating crates.io index
error: failed to select a version for `syn`.
    ... required by package `example v0.1.0 (/tmp/example)`
versions that meet the requirements `=1.0.81` are: 1.0.81

all possible versions conflict with previously selected packages.

  previously selected package `syn v1.0.65`
    ... which satisfies dependency `syn = "=1.0.65"` of package `example v0.1.0 (/tmp/example)`

failed to select a version for `syn` which could resolve this conflict

I think these issues might be related:

• False positive cyclic dependencies when building for different targets #9738
• [target.'cfg(all(target_arch="x86_64", not(debug_assertions)))'] in .cargo/config doesn't seem to work #5777

Steps

No response

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.56.0 (4ed5d137b 2021-10-04)
release: 1.56.0
commit-hash: 4ed5d137baff5eccf1bae5a7b2ae4b57efad4a7d
commit-date: 2021-10-04

[ehuss]

The Cargo team discussed this in our meeting, and we are going to close this as it is intended behavior, and probably not something that can change in the foreseeable future. Particularly for the example given, Cargo wouldn't be able to determine disjoint cfg expressions, as they are somewhat an opaque identifier. Also, Cargo fundamentally unifies so that the behavior is the same across different targets. In the future, public-private dependencies (#6129) may provide some relief here if the dependencies are private, and both are not direct dependencies. However, that is somewhat far off, and uncertain how it will play out.

[JavaDerg]

What is the intendet use of that feature then? I don't see the usecade then.
This is currently breaking one of my projects and i was only able to fix it with a [patch] and forking the dependency with that pinned syn under wasm32.