I don’t think that’s a good solution. Essentially, pyproject.toml is a source file here, and PKG-INFO is the output file here. Expecting people to manually deal with output when source changes is against the principle of the least surprise. To put it in Python terms, it’s as if .pyc files weren’t invalidated when respective .py files changed — i.e. the user would end up editing sources, and then scratching their head why program behaved as before the change.
I can’t imagine anyone telling people they need to remove .pyc files when editing Python sources, nor telling them that they need to add a special marker to .py files to indicate that they’ve edited them. What happens instead is that Python detects that .pyc files are outdated and updates them. And I think that build systems should do the same thing wrt outdated PKG-INFO. Admittedly, it is nowhere as simple, especially that the format doesn’t provide any means of tracking source files used to create PKG-INFO — but even checking mtime of pyproject.toml would be better than the current behavior.
Honestly, I think the biggest problem here is that Python packaging is infinitely complex and counter-intuitive, which means that anyone involved on either end is surprised to find a very high barrier of entry. The Gentoo Python Guide has already 300 KiB of .rst files, and it is by no means comprehensive. At this point, distribution developers pretty much can’t really package anything written in Python without getting a special training and/or senior developer review, and even senior developers have a hard time following the constantly changing landscape.
At the same time, Python framework in Gentoo has already a bunch of safety checks included to detect the most common pitfalls. Again, it is by no means comprehensive and I keep extending it whenever we discover yet another counterintuitive pitfall. This thread makes me think that we will need to add another check to make sure that PKG-INFO is dealt with when pyproject.toml is patched.