The most radical version of this view is that we should have no restrictions on project.toml because it’s just a key-value store – it’s just metadata and tools can do whatever!
That’s obviously a very poor experience for developers, who must learn that “field foo means X under build tool Y” rather than “field foo means X”.
Giving fields clearly specified meanings ensures that developers learn one concept and carry that same meaning across tools. That doesn’t mean that the defined behavior can’t be expansive or even intentionally non-specific, but it must be defined. Vagueness is not a virtue in specifications, after all.
The current Requires-Python field (showing my bona fides by using the name in the metadata! 
) is well defined vis-a-vis dependency solvers. It makes a package version an invalid solution for certain target interpreter versions. If you want to reuse the same field in project.toml which populates this for a different purpose… well, I’m pretty strongly against it, but I think you’re going to be to reckon with the fact that you’re making the same config field mean two different (related! but different) things.
At present, I’m feeling pretty skeptical of the idea of multiple configs as standard (if a tool wants multiple configs of it’s own, that’s the tool’s prerogative). Given the breadth of impact here – the whole community, more or less – this is seeming to me like a major and complex change involving inheritance, overrides, append operations, changing field requirements, and some file discovery mechanism.
I’d like to try to stay open to this, but I’m weighing all of this complexity against a new table with one or two fields. By comparison a much more conservative change.