This is an issue that I care a good deal about because of protocol buffers. A protocol buffer message can list messages, fields, etc. as being deprecated, and some generators (including the Swift implementation) map that to the target language's deprecation annotation.
Unfortunately, the code that gets generated for the implementations of the messages themselves also needs to touch the deprecated properties in order to serialize them; the implementation can't just drop the deprecated fields if a client or server still sets them or expects them. So separate from any concerns about warning external clients about deprecated usage, compiling the generated protobuf code itself produces a slew of deprecation warnings that aren't actionable without jumping through some hoops to change the code that we generate (to add some indirection to separate the underlying storage from the public properties, which could have performance impacts, but those might be lessened now due to some other language enhancements that happened recently). But what's worse is that protocol buffer generated code can't be successfully compiled at all if it contains deprecated fields and the user wants to use -warnings-as-errors.
I pitched some ideas a little over a year ago to address the specific issue of deprecations, initially to just suggest suppressing deprecation warnings from references in the same file, but other folks responded with valid scenarios where they wanted the module to be the boundary. @xwu's idea of adding an access level to deprecated that specifies where uses of that symbol should actually be considered deprecated is an interesting one.
It seems like an approach that uses such semantic information to eliminate spurious or non-actionable warnings at the source would be preferable to letting users just suppress individual occurrences and would be in the spirit of how the Swift team views these diagnostics.