I believe for what you're doing (type-punning memory buffers) only the memory layout (size, alignment, field offsets) of types is relevant. This is already a big ask, but the calling convention part of "the ABI" have been considered even less.
The Unsafe Code Guidelines working group has written up some layout guarantees -- a mix of documenting pre-existing commitments and proposals that are not yet accepted by the language. However, as you will see, that does not include any semblance of "layout stability" for many aggregates types without an explicit repr(..) attribute. Back when this was discussed, we couldn't even get consensus among the (relatively few) people participating that layout of e.g. structs should be a deterministic function of the entire compilation inputs (e.g., some people want to be able to randomize struct layout), let alone of the layout of the struct's fields (e.g., some people want to be able to lay out each struct differently depending on how its fields are accessed at runtime, like profile-guided layout).
So the answer right now is (for enough types that the exceptions aren't very interesting)
ABI and even layout can change between any two compiler invocations even if they are 100% identical
and this will remain true even if more currently-proposed layout guarantees are accepted.