Unsurprisingly, I’m still in favour of the overall concept 
I also like the idea of making the initial iteration as simple as possible and deferring the ergonomic improvements until the base API has had more exposure and opportunities for third party experimentation.
I did notice one small issue in the text: the discussion of PEP 573 needs updating to reflect that PEP being finalised back in Python 3.9.
I’m less sure about the “known issues” listed in the “Interpreter Isolation” section - I thought some of those had been addressed since the early iterations of this PEP were published, but I may be misremembering.
In the section on resetting the state of the main module, an “Interpreter.copy()” method to create a preinitialised interpreter from an existing one should be listed (I’m not saying such an API would be easy to implement, especially if extension modules have been imported - it’s just explicitly noting that figuring out interpreter snapshots is one of the potential design options to offer “reset back to a previous state” functionality)
The section on returning a value gave me another sample recipe idea: redirecting stdout in the subinterpreter to a pipe that the parent interpreter created.
Given your conclusions in this discussion thread, the short “Auto-run in thread” subsection should be removed, as it is contradicted down in the rejected ideas section.
In the “Rejected ideas” section, the discussions of pipes and queues still reflect the earlier “channels included” API proposal. I think the discussion of the implementation state is also affected by this.