I think for an Intent to Prototype, you should be able to just reply to the previous I2S and give people a heads-up about the exposure. I2Ps don't require any approval, and we don't want to make them a heavyweight process.
The eventual I2S is more interesting. I think either approach could work, but since shared workers are pretty different from windows/dedicated workers (e.g. around permissions), I suspect a new ChromeStatus entry would work best.
In particular, I'd expect a discussion of: security/privacy implications of this new exposure; debuggability; web developer signals/what's the motivation for doing this. And we'll want to see artifacts like: the spec PR that adds this exposure, the WPTs that cover this exposure, the new Finch flag this is launched under; and a design doc if there is one.
So to be concrete, I'd recommend sometime between now and I2S:
- Updating the existing explainer with a small section on shared worker behavior (or maybe worker behavior in general)
- Updating the spec
- Creating a new ChromeStatus entry to encapsulate all the stuff I mention above
and then you can use this new ChromeStatus entry to generate the I2S email.