1) for me, if you have to explain a name better, then it is already a bad name. Intuitively suggesting the correct interpretation to another developer, without requiring him to thoroughly read through the documentation, is the art of picking good names (which imho Groovy overall does a good job at).
With regards to @KnownImmutable, "someone (the compiler or the developer) knows" is even more confusing. If it is in fact irrelevant who knows it, why is there a "Known" in the name in the first place ? And why is therefore e.g. @IsImmutable not a better name (it could also carry a parameter which can be true or false, with false allowing a developer to express that a class is definitely not immutable (even if it might look that way on first glance; e.g. effectively blocking or issuing a warning in certain parallel execution scenarios)).We have since the introduction of @Immutable used the knownImmutable and knownImmutableClasses annotation attributes and people seem to grok what they mean. This is a very similar use case. I think it would be hard to justify renaming @KnownImmutable without renaming the annotation attributes as well.