Marcin Jaczewski wrote:
But attributes "failure" should be preferably "invisible" and "undetectable"?

Should it, though?  As Timur said, he wrote a proposal that said attributes should be ignorable, and that wording got into (a note in) C++23. But should it have? Attributes are just part of C++'s syntax — they're part of the language — and they are "non-ignorable" in the same sense that `if` or `const` are "non-ignorable." Attributes, similar to keywords like `if`, have very real intended effects on the program's semantics, and it's certainly a problem for the working programmer if the compiler is allowed to just ignore part of the programmer's code.
The "ignorable attributes rule" is defensible only by semantic arguments, such as:
- WG21: "Attributes can be ignored, but a quality implementation should of course voluntarily support them."
- Working programmer: "Okay, then, I choose to use only quality implementations, because my code won't work as intended on non-quality implementations."
- WG21: "Okay, we'll give you a way to detect whether an implementation is quality or not."

If a construct were truly "ignorable," then the working programmer wouldn't write it at all; there's no sense in writing something that will have no effect in practice. (He writes, ironically.)

Like `[[noreturn]]` you can't easily detect that the compiler generates useless return handling.
`[[no_unique_address]]` probably is a bad attribute as its "failure" causes UB and portability problems.
I personally think that `no_unique_address` should be the keyword as this affects ABI, then if compiled do not support it it will simply reject the program.
I now do not recall any other attribute that the compiler needs to implement otherwise it would break something.

[[no_unique_address]] is "ignorable" as a QoI issue (as above).
You can tell whether the compiler ignored it or not by inspecting `sizeof(T)` after the fact.

Another example close at hand is P1144's proposed [[trivially_relocatable]], which is "ignorable" as a QoI issue.
You can tell whether the compiler ignored it or not by inspecting `std::is_trivially_relocatable_v<T>` after the fact.