While working on gopls, we have a few places where (for example) *ast.Object or *ast.Scope are handled in a type switch or type assertion, and the deprecated analyzer produces informational diagnostics for their usage.

I wonder what is the generalization of this classification of symbol references into two classes that we might call "analytic" (deconstructors: type switches, comparisons, etc) and "synthetic" (constructors: var decls, literals, calls, etc)?

Is there no case where the deprecation notice is useful in type switch or comparison?
Let's say a type A is deprecated in favor of a better new type B in a new release. If I have a type switch on A but don't have B yet, learning about this new deprecation notice will help me update my code based on my application's need - maybe I have to continue having A case handling, or, maybe I am lucky enough to stop thinking about A.
On the other hand, it's annoying that there is no suppression mechanism after I already verified the use of deprecated symbol in my type switch code is working as intended.

I think the case for this notice being useful here is slim -- the example you suggest would be better handled by some sort of search for inexhaustive type switches.

We aim for very low false positives, so I think we should suppress this diagnostic.

Should the use for type assertion, comparison be also suppressed? Should there be an option?

The current analyzer suppresses information about the usage in the same package for the same reason but I keep receiving questions related to this. Just got another one - #40447 (comment) I think this is one of the analyzers where people have different taste and need.