It sounds like you want to propose a competing PEP that provides your kwkey as a built-in as an alternative to PEP 637.
I encourage you to do so, although I have no interest in acting as sponsor, and I fear that your window of opportunity to write a competing PEP is small.
Alternatively, you could write a PEP that proposes a new kwkey object as complementary to, not competing with, PEP 637. That would provide a "kwkey" builtin similar to slice(), and people can explicitly opt-in to using it:
# plan old PEP 637 semantics obj[spam, eggs, cheese='cheddar', aardvark=True]
# explicit use of kwkey obj[kwkey(spam, eggs, cheese='cheddar', aardvark=True)]
Another possibility is that you are not advocating for subscript keywords, and you prefer the status quo. (Your kwkey project counts as the status quo. It involves no new syntax or language features. Anyone can write their own kwkey class, or install a third-party library to use it.) Perhaps you agreed to co-author PEP 637 to have it rejected once and for all, not accepted, and you think that the current PEP is not neutral enough and advocates too strongly for the feature.
PEPs can, and often are, written to be rejected. The PEP then becomes the canonical record of why the feature has been rejected. It is unfortunate if you and Stefano had radically opposite reasons for writing the PEP, but I think that's something the two of you should sort out and find some middle ground.
Unfortunately Jonathan, I cannot tell from your post what your purpose is. I cannot tell if you oppose or support PEP 637, whether you want to propose a competing PEP, a complementary PEP, or just want to get credit for your kwkey project by having it mentioned in the PEP, or what exactly you want.
I will comment further on the details in your post in another message.