Agree with @Jumhyn’s view overall.
I differ on the issue of import-level deprecations because the use cases presented above relate to entire libraries being deprecated without equivalent replacement.
Individual deprecated functions, etc., can be feasibly dealt with by re-declaration or in other ways (even re-implementation sometimes), but an acknowledgment per use site or these workarounds you mention aren’t really an answer to the problem where, say, all of WebView is deprecated.
The user intention that we want to make possible to express here is, “Yes—I know WebView is deprecated but I want to use it anyway,” which is not best served by re-declaring the entire API surface of WebView or annotating every call to a WebView API.
On the other hand, I am not sure I understand what problem is uniquely addressed by a project-wide compiler flag to silence all deprecation warnings—this would mean that a user wants to use any and all deprecated APIs from any modules and in any place without thinking about it, and I’m doubtful this is desirable to enable.
This goes to my concern above about scope-level deprecations too. The core of where I agree with @Jumhyn lies (to my understanding) in that we both think it’s important that the user to be able to express an intention of the form “I know ‘X’ is deprecated but I want to use it here” for some specific “X” and for some granularity of “here.”
We may differ somewhat on the level of specificity we are comfortable with, but we’re both wary of features that enable silencing of deprecation warnings from who-knows-where, as it’s not really an expression acknowledging awareness of what warnings are actually being silenced.