Thanks @miketheman!
This came out of the original discussion in Pre-PEP discussion: Project status markers in the Index APIs – @ncoghlan observed in Pre-PEP discussion: Project status markers in the Index APIs - #11 by ncoghlan that meta is intended for metadata about the response, rather than the response’s own metadata (since the entire response is itself arguably a form of metadata about a project).
In this case, I agree with her rationale (and @pf_moore’s rationale in the following comment) – meta mostly gets currently used as a signaling layer for things like mirror clients (hence _last-serial), not as a boundary between index- and package- controlled metadata itself. yanked and provenance are examples of this, since both are conceptually index-mediated but appear side-by-side with release-file-mediated metadata 
No strong opinion from me, but out of curiosity: do you see a procedural advantage to deferral versus the existing MAY language in the PEP? For reference:
Indices MAY implement any subset of the status markers specified in this PEP, as applicable to their needs.
I think my main argument for keeping deprecated in the PEP is that it probably is something that PyPI (and other indices) will eventually want to implement, so standardizing it upfront means not having to do another PEP cycle (plus metadata version bump?) when the time comes.
(FTR, I would like to push a deprecation marker forwards on PyPI – IMO it’s a useful discrete signal/state beyond archived and gives maintainers the ability to express “no new features coming, but you might see the occasional bugfix/security release.”)