Isn't it the case tho, that a PEP is usually just a document + discussion? I've seen someone having a PoC sometimes, but iirc it's not often readily available for use.
Unless a feature is available to try (in alpha, beta, whatever), people can't really evaluate its ergonomics and how it affects or integrates with their use cases.
I know that at least a few languages, including Go and Rust, don't commit to a feature after the relevant proposal is accepted, but have version you can try, that they might change and/or revoke.
As someone in the Python community often says, "there must be a better way"!
Maybe a PEP could include the stage where there is something like a "from __pep_proposals__ import new_feature".
This might slow down the PEP rate (if every new candidate feature needs a trial implementation), but that's not necessarily a bad thing. Or it could just be required for larger changes to the language.
(THE RaymondH? !!!)
This isn't always true, but I've seen it be the case for most recent peps.
That shouldn't be the case. There should be a PEP-re-evaluation stage, once the feature is available.
It might not affect major parts of the PEP (that should be handled in the original PEP discussions), but for things that are found to be problematic in actual use, once the feature is available in beta, changes should be considered before the final release.