To answer generally, the relationship between the implementation and the review process is that we require at least a prototype implementation be provided prior to scheduling a review. This prototype need not be in any sort of mergable state, and we do not make an effort to validate that it is entirely bug-free. Rather, the purpose of this requirement is to ensure that there are no major holes in the proposed semantics that would make them fundamentally unimplementable, and also to ensure that there is someone involved with the proposal who could feasibly take on the project of getting the implementation landed on main.
Prior to this requirement, it happened a few times that proposals came to the mailing lists, were reviewed and approved, and then either nobody took on the implementation project (leaving the proposal to languish), or else it was discovered during implementation that there was some serious issue with the proposal which required another round of review to settle.
To answer your specific questions:
- does the LSG consider the proposed implementation and any associated PR discussion in its determinations?
No, specific implementation details are generally considered out of scope for proposal review and the LSG does not cover PR comments as part of our decision. The extent to which implementation concerns factor into the review process is basically limited to a feasibility analysis. More recently we've also made an effort to ensure that the implementation also be made available in a toolchain/package so that reviewers can evaluate the feature by using it themselves, and I'd say this admits one additional exception to 'implementation feedback is out of scope for review threads', which I mentioned during review:
- are proposal authors expected to respond to implementation feedback during the review?
No, it is not expected that implementation feedback be addressed during review. The review process and implementation process are only loosely coupled in the specific following ways:
- A prototype implementation must be provided in order to bring a proposal to review.
- Accepted proposals must have their implementations landed within one year of acceptance or else they are subject to re-review.
- Public changes to the language surface must go through LSG review before they are released.
Beyond that, implementation proceeds largely independently of the review process. Whether PRs are merged is governed by the maintainers of the compiler repo and the LSG's formal role ends once we have approved or rejected a proposal. It is not uncommon for implementations to undergo substantial changes after being accepted, or to require several follow-up PRs to sufficiently harden the implementation.
- are review managers typically familiar with a feature's implementation and any PR feedback, or is that outside of the role's purview?
The RM is responsible for ensuring that proposal authors have provided an implementation of sufficient quality to validate a substantial portion of the proposed semantics. However, as mentioned above, monitoring implementation feedback is not part of the review process.
I don't want to come across as though I'm being dismissive about your implementation concerns—I think you raise good questions about how community members can best surface this sort of feedback, but I don't believe proposal reviews are the right venue. This could be a good discussion to raise in Contributor Experience!