Note: I think the PEP text is currently pretty unclear about what it means by "anonymous arguments". In 3.8+ we have syntax for those (via PEP 570), but you're not using that syntax here, and it would be unfortunate if this feature were restricted to projects that have adopted 3.8+ only syntax...
For the record, the syntax for anonymous arguments I'm using here is defined in PEP 484 (https://www.python.org/dev/peps/pep-0484/#positional-only-arguments). I'll try to make that more clear in my new draft. Furthermore, in my forthcoming draft, these are no longer required to be declared as positional-only, but rather just be used as if they were positional only. I don't think that's particularly relevant to the concerns you have, but is worth mentioning. The new draft still bans adding keyword only arguments, and tries to do so a bit more clearly.
...then the PEP does allow your example, but you still get the same error at runtime.
I don't believe that it would be accepted. If you don't add on `special_kwarg` then it would be an error to call the function with it, avoiding the problem. If I'm misunderstanding you, then could you give me a complete example of what would be accepted by the PEP but would still have a TypeError at runtime.
Also, even if we fail to catch this error, is that a problem? Python type annotations don't try to guarantee that all errors will be caught statically.
One of our long term goals with Pyre is to support an expressive yet sound type system so that we can eventually make those guarantees. Therefore, when introducing new features like this, we're expressly trying to not introduce unsoundnesses that we will eventually have to come back and patch out later. This means that we aren't going to be able to support all use cases with these features. Ultimately the issue of adding named parameters onto ParamSpecs has more problems than just soundness issues, there are implementation and syntax concerns. * implementing positional only concatenation is already pretty tricky, and adding names along for the ride makes implementation significantly more challenging. For a PEP that hasn't been implemented by any other type checkers yet, this imposes a significant burden for adoption. * Spelling the type of a function like `run_in_thread` would introduce another scenario where we would require you to drop down into callback protocol syntax, which is already unfortunate and a source of confusion for users. For more details, I have a draft version of the reworked PEP up here: (https://github.com/python/peps/pull/1424), and in a fully-commentable form here: (https://github.com/mrkmndz/peps/pull/1). Overall I think this is a reasonable request, and I think it's possible to soundly support it via "banned name" constraints on ParamSpecs. However I think that it is complex enough to merit a separate PEP.