The fact is that there are programs which behaviours depend on whether the implementation chooses to ignore this particular attribute or not. Perhaps that is fine, but perhaps not. As noted in the draft proposal, Microsoft has also been unwilling to implement [[no_unique_address]] in its ignorable form because it would cause an insidious ABI incompatibility depending on the language standard in use.
How does your proposal help with that? Assuming your proposal got into C++26, you wouldn't be able to use [[!no_unique_address]] in C++23 or older, so you'd have exactly the same problem.
struct A {
#if __cplusplus >= 202600
[[!no_unique_address]]
#endif
B b;
};
How does this help?
If your intention is to somehow force MSVC to support the attribute, I don't think your proposal achieves that. They will just refuse to support the new form as well, because it has the same issues (older versions of MSVC will not support the attribute, whether "required" or not, and so the same risk of ABI incompatibility exists for any code using it). So the proposal is not well motivated.