> I'd expect it to work with _any_ type, primitive or not, newtype or not, with a sufficiently simple memory layout, the rough equivalent of what C++ calls a "standard-layout type" or (formerly) a "POD".

This might be related in part to the fact that Rust chose to create specific AtomicU8/AtomicU16/etc. types instead of going for Atomic<T> like in C++. The reasoning for forgoing the latter is [0]:

> However the consensus was that having unsupported atomic types either fail at monomorphization time or fall back to lock-based implementations was undesirable.

That doesn't mean that one couldn't hypothetically try to write from_mut_slice<T> where T is a transparent newtype over one of the supported atomics, but I'm not sure whether that function signature is expressible at the moment. Maybe if/when safe transmutes land, since from_mut_slice is basically just doing a transmute?

> Shouldn't it work when T and U are the same size and T has stricter alignment requirements than U but not exactly the same alignment? In this situation, any U would be properly aligned because T is even more aligned.

I think this optimization does what you say? A quick skim of the source code [1] seems to show that the alignments don't have to exactly match:

    //! # Layout constraints
    //! <snip>
    //! Alignments of `T` must be the same or larger than `U`. Since alignments are always a power
    //! of two _larger_ implies _is a multiple of_.

And later:

    const fn in_place_collectible<DEST, SRC>(
        step_merge: Option<NonZeroUsize>,
        step_expand: Option<NonZeroUsize>,
    ) -> bool {
        if const { SRC::IS_ZST || DEST::IS_ZST || mem::align_of::<SRC>() < mem::align_of::<DEST>() } {
            return false;
        }
        // Other code that deals with non-alignment conditions
    }

[0]: https://github.com/Amanieu/rfcs/blob/more_atomic_types/text/...

[1]: https://github.com/rust-lang/rust/blob/c58a5da7d48ff3887afe4...

Wild performance tricks