Decide the intended relationship between `core::$module`, `alloc::$module`, `std::$module`

All of the following designs are in use for various standard library modules:

1. core::$module ⊆ alloc::$module ⊆ std::$module
2. core::$module ∩ alloc::$module = ∅, (core::$module ∪ alloc::$module) ⊆ std::$module
3. something else, intentionally
4. something else, unintentionally

Is one of these a good design that should ideally be getting applied for all modules?

Some other examples where an item in core::$module and/or alloc::$module does not appear in std::$module:

• core::char::encode_utf8_raw
• core::char::encode_utf16_raw
• core::error::Source
• core::ffi::va_list
• core::iter::InPlaceIterable
• core::iter::SourceIter
• core::iter::TrustedFused
• core::iter::TrustedRandomAccess
• core::iter::TrustedRandomAccessNoCoerce
• core::ops::Receiver
• core::ptr::Thin
• core::ptr::Unique
• core::slice::memchr
• core::slice::GetManyMutError
• core::slice::SlicePattern
• core::str::next_code_point
• core::str::utf8_char_width
• core::panicking
• core::range
• core::ub_checks
• core::unicode

Start by comparing the listed exports across the core, alloc, and std module entry points, including the alloc, sync, panic, and ffi::c_str examples. Review the remaining examples that are absent from std and use the issue's four designs to frame the discussion; done requires an agreed intended relationship, not an implementation patch.