In summary, it seems the community consensus (and certainly my own opinion) is to strongly discourage this pattern this for multiple sets of reasons, as I and many other folks here describe on
As that’s getting rather OT for the thread, if you have further feedback/points to consider on that, I suggest replying other there (or creating a new thread).
What’s seemed to work well (IMO) for PEPs in the recent past has been adding the pre-draft-PEP in a branch on your fork of the PEPs repo, with a PR of that branch against main for textual comments. I suggest keeping substantive/conceptual discussion here to be easy to follow and consider later, whereas comments/suggestions on the PR work well for textual clarifications and the like.
As @henryiii mentioned and as implied in my post you quoted originally, the potential advantage here is if a metadata key is going to be specified as dynamic anyway, defining strict, clear and explicit semantics for also including it in [project] still allows many tools to extract considerable value from it if they can rely on what can and can’t change, or at least provide a constrained best-guess. Its certainly not ideal, but it’s better than having the key be completely opaque to tools and require building the project/running arbitrary code for all use cases instead of merely some of them.
NB, I don’t necessarily disagree with your conclusions, but I can see where @pf_moore 's confusion comes from. IMO, it would make the most sense (and be most conservative) to show a comparison with the status quo that we have today (i.e. no new top-level pyproject.toml key) as well as pointing out where that falls short when it comes to the motivation of this proposal.
IMO, but if the pyproject.toml already exists checked-in to the project source tree, a backend shouldn’t rewrite it (at least outside the [tool] table) in the sdist, or this makes the [project] table (and [build-system] table, etc) non-static and thus not reliable, defeating the design goal. (If it isn’t present and only dynamically generated by the backend and added to the sdist, then this doesn’t apply).
Yes, just in the PKG-INFO in the sdist rather than the pyproject.toml (and it requires the keys are marked dynamic in the original pyproject.toml, of course). A backend can of course dynamically generate/process pyproject metadata keys marked as dynamic (or any key, if there’s no [project] table at all) and insert them into the PKG-INFO in the sdist, and then not list them in the Dynamic core metadata field for sdists added in PEP 643 for Core Metadata 2.2, meaning they are static and thus reliable for all wheels generated from the sdist.
Unfortunately, no, because AFAIK like several other packaging PEPs this is ultimately blocked on PyPI adding support for Core Metadata >2.1, which has unfortunately been the case for years now.