I think so, insofar as PyPI should have access to its own linehaul/BigQuery statistics. But that one stood out to me as the constraint/policy control that I’m least confident about actually implementing, in part because I don’t know how slow (or expensive) it’d be to periodically query every new package 
Thanks for raising this – I wasn’t sure if it belonged in this (planned) PEP or not, but I’ve been thinking about a long-term solution to the quota problem on PyPI as a logistical blocker to actually rolling out restrictions on deletion.
In other words: my approach here was going to be (1) write a deletions PEP, (2) implement that PEP behind an admin flag, so that it has no effect until the larger quota problem is solved. But perhaps that order is backwards, and the PEP should explicitly discuss resolving the quota problem? Curious what you think!
I agree! This is another thing I wasn’t sure about including in the PEP, or leaving for a later point: my colleagues and I have also been given some time to work on a “project status” reporting mechanism for PyPI, which would (in principle) include the ability for maintainers to say “sampleproject is deprecated and abandoned, we recommend you consider sampleproject-ng” within structured metadata.
That alone has several degrees of freedom, so I didn’t want to make the PEP into “address everything that’s currently non-ideal about package lifecycles.” But like with the quota stuff, I’m happy to adjust the PEP’s scope to the community’s expectations, rather than bring things up piecemeal 