This is the issue form of #2085, since we didn't have one. A past proposal was #2583, although I don't remember precisely why we rejected it. This also affects #3296.

For this issue I'll assume we've resolved on #2119 that error scopes never have a blocking effect on forward progress.

Right now, we have two APIs:

• createPipeline: Create a pipeline, give it to me now, and don't tell me when it's ready.
• createPipelineAsync: Create a pipeline, but don't give it to me until it's ready.

What we're missing is "Create a pipeline, give it to me now, but tell me when it's ready." As described in both of the issues linked above, the only way to get this with the current API is for implementations to internally deduplicate pipeline requests and "join" the background thread that's doing the async compilation. This is technically fine, but I think it's really weird for developers to work with.

I think part of the difficulty here is that we've been discussing this issue as if there are two modes (sync and async), when in fact there are three: foreground thread, background thread with reportback, and background thread without reportback.

I think in principle, we added these APIs to control reportback, moreso than foreground vs background creation.

On #2583, Corentin says that it's important to give control over foreground vs background, while Dzmitry says that in createPipeline "implementations are still highly incentivized to do work" on background threads. I think any control we give over foreground vs background would be a hint anyway, as it's unobservable.

[proposal removed, see post-v1 proposal below]