Clarify note stating that reading uninitialized padding is permitted

The reference says:

• Producing an invalid value, even in private fields and locals. "Producing" a value happens any time a value is assigned to or read from a place, passed to a function/primitive operation or returned from a function/primitive operation. The following values are invalid (at their respective type):
  • [...]
  • An integer (i*/u*), floating point value (f*), or raw pointer obtained from uninitialized memory, or uninitialized memory in a str.

and then later:

Note: Uninitialized memory is also implicitly invalid for any type that has a restricted set of valid values. In other words, the only cases in which reading uninitialized memory is permitted are inside unions and in "padding" (the gaps between the fields/elements of a type).

What would be an example of reading uninitialized padding memory? Does this mean that reading uninitialized padding memory is an exception to the above rule (I'm guessing not, but I don't know how to interpret this note otherwise)? Would ptr::read::<u8>(ptr_to_padding) be considered "permitted"? Or does it only mean that ptr::read::<MaybeUninit<u8>>(ptr_to_padding) is "permitted"?

I think this note is unclear and should be reworded. The second sentence also starts with "In other words ...", but these two sentences seem like completely different ideas.

Start with the linked Rust Reference section on behavior considered undefined, especially the invalid-value list and the note about unions and padding. Compare the note's two sentences and the ptr::read examples in the issue, then clarify the distinction so the permitted cases and their limits are unambiguous. Done means the wording directly answers the padding-reading questions without changing the documented semantics.