There are already projects that use custom attributes for testing etc, such as kani that can do model verification, and there are several possible tools that could have a use for such attributes. Currently, the solution is to use proc macro attributes which require a dependency and if the dependency is used only for testing or other non-compilation tasks then one has to write annoying #[cfg_attr(kani, kani(...))].
How about defining a namespace for external tools which could define their attributes outside of proc macros, without needing to use conditional dependencies? E.g. it could look like #[external::kani(...)], where the convention would be to use the name of a crate on crates.io to prevent conflicts (corporate projects can define their conventions for out-of-registry crates). The compiler would not warn/error about that attribute not existing and simply ignore it. This is similar to [package.metadata] key in Cargo.toml.
This could also unlock parallel experimentation with new ideas and some of them could make it into the compiler if proven useful. For instance there was an idea to have an attribute for marking renames of items so that downstream crates could migrate more easily by running cargo fix. Rather than waiting on approval and testing of that idea one could whip out a PoC using syn that parses the attributes and combines them from rustc output to get the names of missing items and apply them automatically. (This is something that would've been useful to me, though cargo fix with the YOLO env var can do it too, so I don't bother.) As another idea, c2rust could emit more information about the original code that could be then used by a refactoring tool that helps getting rid of unsafe.
BTW, some of you may have noticed I've recently proposed a new attribute - this has nothing to do with it, that proposal really belongs to the compiler, not external tool, I think. (This note is mainly to not come off as frustrated about that proposal which I'm definitely not, quite contrary.)