Some quick thoughts.
The objective is to make users feel confident that their code is not going to break by future releases of Rust; to convey that building a reliable software ecosystem is of primary importance to the project; we have effective processes in place to prevent regressions.
Some points to convey:
- Rust is committed to maintaining a rock-solid system, while still evolving it carefully.
- Rust has a policy that governs precisely what types of changes to the language are allowed.
- Rust has a policy that governs Rust’s interpretation of semver, determining what changes may be made to the standard library between releases.
- Rust uses advanced testing strategies to ensure the rules are followed. Not sure how much to press this here. We can still do a lot more than we are with tooling.
- Users have recourse when they discover invalid breakage. What is it? File a bug? Ask for it to be taged I-stable-regression?
We might also summarize the basic rules from both RFCs in a simple way.
To your specific question, I’m not sure it needs to be as detailed as "don’t poke at struct layout", as long as that information is in the linked RFC’s. I do think it’s worth specifying the basics of what is and isn’t defined, just enough to give you the general sense of the policy, and including struct layout in that is sensible.