> memcpy has well defined behavior, regardless of how it's implemented. If
> the program says memcpy then the source is copied as is to the target,
> with padding bits and everything. I do not see a fundamental reason why
> then the target should not be allowed to be used.
>
> Because the source could also not be used. For all intents and purposes,
> padding bits are eternally indeterminate quantum bits, and querying
> their value results in your CPU exploding.

This premise is too disconnected from reality.

Look, even the standard acknowledges that objects are represented with
bytes stored in some kind of storage.

No, this is wrong. See the aforementioned examples.

Eh, I've added one too many "No"s here. Objects are stated to be made of bytes, so that much is correct. The issue is that whether those bytes actually exist in hardware or merely on paper is unpredictable outside of debug builds, so an "abstract machine byte" has little to do with a byte of memory in hardware.