Harmonize wordings of "All [such] specializations of [some STL template] are trivially copyable"

Inspired by the NB comment about making optional<T&> trivially copyable, I think it would be nice to harmonize the wordings of

https://eel.is/c++draft/utilities#refwrap.general-2 "reference_wrapper<T> is a trivially copyable type"
https://eel.is/c++draft/utilities#func.wrap.ref.class-2 "Each specialization of function_ref is a trivially copyable type ..."
https://eel.is/c++draft/saferecl.rcu.base#6 "... all specializations of rcu_obj_base<T, D> are trivially copyable"
https://eel.is/c++draft/mdspan.extents#overview-2 "Each specialization of extents ... is trivially copyable."
https://eel.is/c++draft/inplace.vector.overview#5 "Let IV denote a specialization of inplace_vector<T, N>. ... IV is trivially copyable"
https://eel.is/c++draft/simd.mask.overview#1 "If basic_mask<Bytes, Abi> is enabled, basic_mask<Bytes, Abi> is trivially copyable"
https://eel.is/c++draft/simd.overview#1 "If basic_vec<Bytes, Abi> is enabled, basic_vec<Bytes, Abi> is trivially copyable"
https://eel.is/c++draft/mdspan.mdspan.overview#5 "A specialization of mdspan is a trivially copyable type if ..."
and perhaps
https://eel.is/c++draft/input.output#file.native-2 "The type native_handle_type ... is trivially copyable"

Personally I think:

• The simplest wording is "For any T such that [...] and any N such that [...], foo<T, N> is trivially copyable."
• That is, words such as "a [...] class," "a [...] type," "all specializations of," etc. are noise that should be removed.
• The entire area could be muddied by the language-lawyer idea that the user is allowed to specialize any of these templates for his own types, and then it's not so clear what we mean by "is" — but I think officially what we mean is "if your user-defined specialization isn't, then you are IFNDR ([namespace.std]/2)," which is actually fine, so there's no problem.

Applying my druthers aggressively would result in e.g.:
https://eel.is/c++draft/utilities#refwrap.general-2 "For any T, reference_wrapper<T> is trivially copyable."
https://eel.is/c++draft/utilities#func.wrap.ref.class-2 "For any F, function_ref<F> is trivially copyable and models copyable."
https://eel.is/c++draft/saferecl.rcu.base#6 "For any trivially copyable D, and for any T, rcu_obj_base<T, D> is trivially copyable."
https://eel.is/c++draft/mdspan.extents#overview-2 "For any IndexType and Extents..., extents<IndexType, Extents...> is trivially copyable and models regular."
https://eel.is/c++draft/inplace.vector.overview#5 probably just don't touch for now
https://eel.is/c++draft/simd.mask.overview#1

For any Bytes and any Abi, basic_mask<Bytes, Abi> is a complete type which is:

• disabled, if there is no vectorizable type T such that Bytes is equal to sizeof(T),
• otherwise, enabled, if there exists a vectorizable type T and a value N in the range [1, 64] such that Bytes is equal to sizeof(T) and Abi is deduce-abi-t<T, N>,
• otherwise, it is implementation-defined if such a specialization is enabled.

For any Bytes and Abi, if basic_mask<Bytes, Abi> is disabled then it has a deleted default constructor, deleted destructor, deleted copy constructor, and deleted copy assignment. In addition, only the value_type and abi_type members are present.
For any Bytes and Abi, if basic_mask<Bytes, Abi> is enabled then it is trivially copyable.

https://eel.is/c++draft/mdspan.mdspan.overview#5 something like "For any Ts..., mdspan<Ts...> is trivially copyable if its accessor_type, mapping_type, and data_handle_type are all trivially copyable."

But at a minimum, we could harmonize the relatively straightforward cases: https://eel.is/c++draft/utilities#refwrap.general-2 with https://eel.is/c++draft/utilities#func.wrap.ref.class-2 with whatever is the new wording for optional<T&>.

Review the linked clauses in utilities, saferecl, mdspan, inplace.vector, simd, and input.output, comparing how trivial copyability is described. Start by checking the straightforward reference_wrapper and function_ref wording alongside the proposed optional<T&> wording. Done means the agreed cases use consistent wording without changing their technical requirements.