I'd definitely prefer one of the names with "overlap" in it.
-
all the alternative names like marker/empty/trivial/simple/basic all fail to convey to the reader what is actually being enabled by the attribute
-
as @Centril pointed out, those names create an awkward "not all empty traits are
#[empty]traits" situation -
the concept of "overlapping" impls is something you already need to understand for the orphan rule and specialization and so on.
This argument doesn't really work for me because overlapping is an opt-in feature. If allowing overlap was automatic and this attribute was about, say, making a public API commitment to never make the trait non-trivial so that client crates could also write overlapping impls, then this would be more persuasive.
As for which overlap-using name, I have no strong opinions, but I do want to throw out the additional paint color of #[impls_may_overlap] since I think there's some precedent for using may like this.
I always assumed the intended metaphor is that the type and trait are the "parents" of the impl, because an orphan impl is (very roughly) an impl where both "parents" are far away/in some other crate.
Then again, it's not like the type and trait created the impl then went to another crate to abandon it there before going back to their home crate(s). It's the other crate author that created the impl out of thin air without either parent's involvement, so I guess that's more like a "test tube baby impl"? Oh well.