Built-in attributes are treated differently vs prelude attributes, unstable built-in attributes can name-collide with stable macro, and built-in attributes can break back-compat

Example breakage: Broken build after updating: coverage is ambiguous; ambiguous because of a name conflict with a builtin attribute

Example code:

macro_rules! coverage {
    () => {
        /* .. */
    };
}

pub(crate) use coverage; // `use` here becomes ambiguous

test is similar to a proc-macro, which is exposed via the prelude. It is not a "built-in" attribute.

The reference hasn't really been updated from when that changed. The sub-namespace section also probably should be clearer on what it means to shadow. I also don't have a good explanation why a prelude attribute is treated differently from a built-in one.

Originally posted by @ehuss in #121157

This is an interesting problem that has three aspects:

1. (T-compiler) Built-in attributes like #[coverage(..)] are handled differently versus prelude attributes like #[test], including name resolution.
2. (T-compiler) Current feature-gating of unstable built-in attributes is insufficient: adding a new unstable built-in attribute gated behind a feature gate (e.g. #[coverage]) can still break stable code without any feature gates (e.g. use of a user-defined macro of the same name as the newly added built-in attribute).
3. (T-compiler, T-lang) Stabilization of a built-in attribute can break backwards compatibility: old code can be broken by addition of a new built-in attribute.

It might be tricky to change (or not possible), mostly opened this issue for awareness.

Start by reading this issue and the linked #121157 report, including the coverage macro example and the discussion of test as a prelude attribute. Trace how built-in and prelude attributes differ in name resolution and feature gating; done requires a decided, compatible behavior covering unstable additions, stabilization, and the reference wording.