The patch from the original revision https://reviews.freebsd.org/D36061 was committed after 14 days of no response from python@ and then reverted.
As it turned out Charlie Li (vishwin@) has a proposal for a similar feature: https://wiki.freebsd.org/Python/PEP-517 that I wasn't aware of at the time I created the patch. The commit was reverted due to the collision with Charlie Li's proposal.
Upon a careful review the proposal https://wiki.freebsd.org/Python/PEP-517 is for a combination of local PEP-517 compliance and global PEP-517 compliance. Local PEP-517 compliance means that individual ports are built with a PEP-517 compliant process. Global PEP-517 compliance means that the whole ports tree is converted to PEP-517 and distutils/setuptools aren't used any longer to build Python ports.
It appears that it is best to handle local and global PEP-517 compliance separately due to resource limitations, their different nature, and them being only loosely related. In the first phase local PEP-517 compliance can be implemented, so that individual ports would build according to PEP-517. This would open the way to a lot of new ports to enter the ports tree. Global PEP-517 compliance can be implemented during the second phase.
The patch that I am suggesting implements local PEP-517 compliance (the first phase).
One difference from the https://reviews.freebsd.org/D36061 proposal is that USE_PYTHON=build is used instead of USE_PYTHON=pep517. "build" is user's intent and is also a very easy to remember word, compared to "pep517" that isn't as easy to remember. Otherwise this patch is exactly same what Charlie Li is proposing for individual ports.
The second difference is that USE_PYTHON=build doesn't support the autoplist feature. The involved tools (build/installed) don't support autoplist and it would be unnatural and not in line with the rest of the ports tree to have autoplist just for Python ports.
In short: the patch herein is essentially in no contradiction with https://wiki.freebsd.org/Python/PEP-517. It provides 2 above mentioned improvements, and also splits the whole project into 2 largely unconnected parts therefore simplifying the process.
I am asking for suggestions on how to improve this patch and seeking approval from python@ and others.