Just coming here from #37650 in which a user was mistakenly using a long deprecated field net/http/httptest.Recorder.HeaderMap instead of net/http/httptest.Recorder.Result()

While we use the // Deprecated: notice as the de facto standard for deprecating fields, it might be very useful for one to know when a field was deprecated.

I propose that just like we have api/<version>.txt whose entries are of the form:
pkg <PKG_NAME>, <IDENTIFIER>
that we add another form also within that same directory <api/version_deprecated>.txt, whose line content formats will be the exact same as those for api/<version>.txt, so no change in parser, but an addition would be that GoDoc can then quickly look up what was deprecated and when and render that along.

This way we can make for more powerful tooling like, for example pkg.go.dev could give a deprecation policy notice between versions and is even more advantageous:

• if an organization follows a deprecation policy e.g. 6 months, or 2 Go-releases deprecation policy, we can then have a column that shows when code was deprecated and when code needs to be changed
• when cutting releases, we can produce a list of deprecated content

Many Go deprecation notices are loosely followed because for the longest time we didn't have modules so years later, users would still using deprecated fields. This suggestion could help in issuing stale code notices and not just when they switch to a module and have to suddenly re-write their code. This can help with more powerful refactoring.