I'm really glad we're finally doing this, and am definitely supportive of the language feature as a whole. There used to be a time where the need for this wasn't treated as seriously, so I'm glad we've realized the reality of library maintainers who e.g. maintain libraries across many Swift versions that such feature really is necessary to not drown in a flood of warnings that "we know of but can't do anything about" -- I've encountered many such cases personally, so I'm really looking forward to this! 
Yeah, most definitely @diagnose/@diagnostic please
The name does need improvement though, the @warn isn't good since it's not
Prior art not mentioned in the proposal in other languages would be: the well known @SuppressWarnings(identifier) in Java, or the @nowarn("msg=regex") in Scala. They're both focused on suppressing warnings and the proposal here offers actually more since we can raise the severity level e.g. @warn(DeprecatedDeclaration, as: error).
This is a welcome addition, however it results in a very misleading name ("warn"), as it is not warning at all, it is causing errors (or nothing, where the suppress word would have worked). Saying "warn as error" is very very weird.
Long story short, the only reasonable word I can think of here @diagnose(Group, as: ...), or I'd personally prefer @diagnostic(Group, as: ...), because the "diagnose" (or "warn" make it sound like its presence in source should cause a warning to be emitted tbh).
Others have also already voiced their preference of this spelling, so I hope we can converge one of those forms, that doesn't confuse the meaning of the word warning.
Clarify handling of unknown group identifiers
The proposal doesn't really specify how unknown identifiers are handled, and I really do not want to be littering my code with:
#if compiler(>=6.6) // because BadIdeaWarning was introduced in 6.6
@diagnostic(BadIdeaWarning, ignored)
#endif
public func foo() { }
... only because that warning group was introduced in 6.6 but I'm also maintaining my library for 6.5 and 6.4 etc. It should of course be allowed to #if for a specific version or platform, but I would not want to be forced into doing this only because an identifier was introduced in a recent Swift.
Can we please make sure unknown identifiers are allowed and silently ignored?
There could be some flag to make this a warning or error to make sure e.g. in CI that on latest swift all the identifiers are actually valid.
Alternatively I suppose this could emit a warning... but I feel like then I'd be going around and adding @diagnostic(UnknownWarningGroup, ignored) whenever facing this situation where suppressing a warning new in Swift X, while I'm maintaining X-2 still.
What's the proposal authors ideas here?
Document interaction with --warnings-as-errors
It would be good to clarify the interaction here, it "seems obvious" but it would be better to spell it out here since this will become the reference to the behavior in the future.
I'd expect:
--warnings-as-errors causes all warnings to become errors- except:
- if a warning was downgraded to ignored:
@diagnostic(Something, ignore) -> ignored
- if a warning was kept "definitely a warning"
@diagnostic(SomethingWarning, warning) -> stays a warning (?)
It'd be good to put this clarification next to the -suppress-warnings section
Clarify interaction with peer macros
The proposal just shows interaction with #macros but doesn't discuss macros which introduce new declarations.
For example:
@diagnostic(DeprecatedSomething, as: error)
@Resolvable protocol Kappa ... { ... }
// generates:
// @diagnostic(DeprecatedSomething, as: error) ???
distributed actor $Kappa ... { ... }
Are we leaving it to those decl macros to copy diagnostic attributes OR are we giving control to silence warnings to end users?
Arguably, this is a tool for end users, and if they're using a macro that produces warnings, they may need to silence it? Unless I'm misremembering how warnings are handled in emitted peers.
! I think the flag to elevate this to a warning or error would be a perfect compromise.