Description
Attributes don't participate in binding and binary compatibility in the same way as types/members. Attributes are consumed by other tools and runtime technology and interpreted differently on a case-by-case basis.
APICompat is ignorant of this and tries to help by just asserting that attributes should remain and be unchanged. In some cases this is helpful, but in a lot of cases it create noise and degrades the experience when working with APICompat.
We were aware of this when adding the AttributesMustMatch rule, which is why it's opt-in and configurable with a list of attributes, but we never tracked improving this.
I think that for many attributes we can promote them to non-optional rules and make them on-by-default. Examples are AttributeUsage, StructLayout, TypeConverter, SupportedOSPlatform, Obsolete. When promoting an attribute to have a special-purpose rule we should omit it from the AttributesMustMatch rule.
Other things to consider when addressing this -- should we introduce more information in the AttributesMustMatch diagnostics to make suppressions more targetable, or is a list of attribute exclusions good enough? Ensure we consider the differences in strict vs compatible comparisons -- these seem straightforward for all the cases mentioned above.