This is the issue that swift-protobuf has as well. When a field is declared as deprecated in the original .proto file, we'd like to mark it as deprecated in Swift, but the code internal to the generated type also gets/sets the field during serialization, and that would produce "false" deprecation warnings.
Doing something like public/private wrapping of the field could avoid this, but it's overhead that shouldn't be necessary IMO, so right now we just don't propagate the deprecation information.
Previous discussions on this topic have led to some interesting ideas like visibility modifiers for deprecation (e.g., something can be declared as deprecated everywhere except the same file/the same module) and those would probably work for the situation @millenomi described, but those discussions didn't address having an escape hatch to suppress the warning if you need to use a deprecated declaration in a scope where it was deprecated.