The problem here is that you can’t be sure if the resolver will “see” the new version with the flag present. Depending on the order requirements are processed, the resolver could be restricted to an earlier version before it ever looks at the latest version.
The only reliable way to do something like this is with project-level metadata, I’m afraid.
I think that is fine because eventually unless something is pinning very old versions then all relevant first hit versions will have the flag. In fact it is a good thing because it means that anyone who is currently depending on e.g. pip install numpy==2.3.3 actually building from source would only see the breakage here when updating the version pin.
Consider the problem that is being fixed here and understand that it is mostly not like trying to go from one working situation to another. Currently if the resolver selects a version of numpy that has no suitable wheel then pip would try to build from the sdist and for 99.9% of users that doesn’t work, the build fails and pip exits with an incomprehensible error message.
This is not a situation that is in much danger of being “broken” by pip usually (eventually always) observing the flag and either choosing a better numpy version or giving a meaningful error message. The breakage is for the 0.1% of people who actually wanted pip to build from source and now need to use --no-binary.
They can, but that is a convention and not a standard and I don’t know how widely it’s followed. Having a Max-Python-Version-Tested field in the core metadata would make that more explicit (assuming Requires-Python covers the minimum case). But I’m not sure what resolvers would do with that information other than to make it an implicit upper-bound that applies to all older versions of a project. It would probably also require some tooling to make sure it’s kept up-to-date.