It's even stronger than that: the C++ standard makes no guarantee that in-memory representation of storage does not change between program executions, let alone between different compilers or architectures. To use mapped memory at all outside a single program execution is pure undefined behaviour. You are literally on your own wrt the standard.
While the standard doesn't explicitly define it, at least a POD which doesn't contain pointers generally should maintain representation within the same executable, even if run multiple times.
It depends on your execution environment. An implementation based on an interpreter or JIT may readily perform WPO which changes compile time constants across program runs. You may not think such execution environments common, but I'd remind you of C++ on GPUs, or C++ cross compiled into Javascript. Further on down the line we may have Modules from a Modules store be late stage optimised into locally optimised binaries. Padding, in particular, might be optimisable, especially as we start to support ever larger integer types. Padding with 512-bit integers, for example, is wasteful. What I will agree with is that for a given version of a given toolchain on a given architecture e.g. GCC 7.3 on x64, you currently get stronger guarantees. But you shouldn't rely on anything not explicitly guaranteed by the standard or your toolchain vendor. Niall