Just adding repr(linear) seems odd, it would be an exact duplicate of repr(C). I think this needs to be in a package with a transition plan for removing the "naive linear layout" guarantee from repr(C), and some guidance for "what do we do if repr(C) is added to a type that has no C equivalent" (such as a struct without fields, or a struct with a () field).
It would also be good to summarize the arguments for why we cannot "just" fix repr(C). I forgot which of the many threads it was in, but there was an argument that people rely on it having the specific layout algorithm we document, even if that differs from what the default C toolchain for this target would do. It can't only be an argument of portability since repr(linear) still is not really a portable format: the amount of padding depends on the (target-specific) minimum alignment of the field types.
There are a number of crates that do fun things with unions and using all possible bits. Manual niche optimisation basically. The most obvious example is crates like smallvec/compact_str, that do inline vec/str optimisation for short vec/str.
I don't think they would be affected by these specific changes (AIX, MSVC), but would they still be sound in the face of future architectures if repr(C) no longer has a well specified algorithm, and is "whatever the most common native C compiler does"? How would you even be able to reason about that?
Other examples of crates doing interesting things that could potentially break now or in the future include: zero copy deserialisation frameworks and zerocopy/bytemuck style transmutations.
It does not seem reasonable to break these use cases.