Yanked releases skipped in ranges but allowed on exact pins under PEP 592

PyPI implements PEP 592 yanking, which lets a maintainer mark a release as yanked with a free-form reason without removing the files. The marker is exposed via the project JSON API and on the project page.

Under PEP 592 semantics, installers that support the convention generally avoid yanked releases when resolving a version range, while still permitting installation when a version is exactly pinned or present in a lockfile. Yanking is distinct from deletion, and the yank reason has no enforced structure.

Behavior is installer-dependent and can vary across environments that do not implement PEP 592 or use older resolver logic. Yanking does not remove artifacts from mirrors, caches, or existing environments.

For teams defining dependency policy, the unresolved decision is how to handle pinned yanked versions, since pip installs them silently by default and policy enforcement requires additional tooling.

What is the intended treatment for an exact pin to a yanked release in a build policy? How should teams consistently surface yank reasons when the field is free-form? What expectations should be set for installers that do not respect PEP 592 yank markers?