I personally think it should be a Standards Track PEP. This PEP isn't documenting some detail like PEP 13 or some release schedule, but is instead proposing a rather major change to the interpreter which a lot of us will need to understand in order to support the code (and I do realize the entire area of "what requires a PEP and what doesn't" is very hazy).
Does that also mean you think the design should be completely hashed out and approved by the SC ahead of merging the implementation? Given the amount of work, that would run into another issue -- many of the details of the design can't be fixed until the implementation has proceeded, and we'd end up with a long-living fork of the implementation followed by a giant merge. My preference (and my promise at the Language Summit) is to avoid mega-PRs and instead work on this incrementally.
Now, we've done similar things before (for example, the pattern matching implementation was a long-living branch), but the difference is that for pattern matching, the implementation followed the design, whereas for the changes to the bytecode interpreter that we're undertaking here, much of the architecture will be designed as the implementation proceeds, based on what we learn during the implementation.
Or do you think the "Standards Track" PEP should just codify general agreement that we're going to implement a specializing adaptive interpreter, with the level of detail that's currently in the PEP? I don't recall other standards track PEPs that don't also spell out the specification of the proposal in detail.