Mm, I thought about it some more and that name is not good. I will hopefully have something better when I start drafting. But the basic idea is to have tables like [required-to.build-wheel], [required-to.run] etc. that store separate lists of dependencies that the code might have depending on what you are doing with it. Here, [required-to.build-wheel] is effectively a replacement for [project.dependencies], a name which I think is misleading and unnecessarily focuses the contents of pyproject.toml on wheel-building (and the design imposes a limit that I want to remove). Then, dependencies related to extras go in places like [required-for.extra-name.build-wheel] etc.
The needed Python version will still default to [project.requires-python], because this should be the same no matter what you’re doing with the code. The code was written to some version of the Python language spec, and that doesn’t change because you’re testing it vs. building etc. Maybe there is some pathological case where someone needs to use a different version of Python to run e.g. Sphinx vs. what the code itself should use; but I consider that to be out of scope (an environment task, rather than a code-usage task).