Like it or not, atomic-polyfill and portable-atomic both exist as crates solving the same problem of "providing atomic primitives to targets that don't have them" in different ways. The major difference between the two crates is that:

1. atomic-polyfill depends on critical-section, and expects another crate to define extern functions acquire and release. The critical-sectioncrate uses acquire and release to implement critical sections. If acquire and release aren't defined by an external crate, a link error will occur. In other words, the critical section implementation can be swapped out with another.
2. portable-atomic implements critical sections for all targets within the portable-atomic crate, and does not defer to an external crate.

According to reverse dependencies on crates.io, these two crates don't have any shared reverse dependencies, and some of these reverse deps have 10 million+ downloads. This means it's plausible to have both crates in the same dependency graph. And this means it's also plausible that these two crates in the same dependency graph implement critical sections in different ways.

Is this a soundness problem in practice? I can't visualize one, since types from this crate won't share memory locations with types from atomic-polyfill. But it's enough to get me thinking and open an issue. If it is a soundness issue as opposed to simply "two crates doing the same thing in different ways are in the same dependency graph", is it possible to fail the build if both crates get pulled in, or automatically have portable-atomic be a shim for atomic-polyfill (or vice-versa)?