Considerations for WASI standardization phases

Wasm has a phase process that describes how proposed features progress toward standardization. The process is designed to make it clear how to add to the wasm standard, both in terms of who should be involved and when, and the practical steps needed to ensure that we have all the artifacts we need before we declare things "done".

We'd like to have something similar for standardizing WASI, and it could be broadly similar.
Most of the steps in the process correspond fairly well to what we might want for WASI, and I expect to be uncontroversial but there are a couple of potentially-interesting bits to call out:

1. Aside from spec text and spec tests (which I assume we'll want too) the wasm spec has a reference interpreter, blessed as a single executable standard. Do we want to have an equivalent reference implementation? What should it be and/or what criteria do we want in a reference implementation?

2. To get to stage 4 wasm requires 2 or more "web VMs" to implement the feature. The requirement for multiple implementations helps ensure that a spec is implementable in different codebases with reasonable effort and avoids baking quirks of a particular VM into the standard (which is a good property that we want). Requiring that they be web VMs doesn't make sense for WASI though. So what should the requirement be? What kind of goal or property do we want in an implementation that we consider sufficient to allow a feature to be standardized?

3. At what point and how do we involve the broader wasm CG?

Start with the linked WebAssembly phase process and the 17-comment discussion on this issue. The work is to define a comparable WASI standardization process, including expectations for a reference implementation, independent implementations, and broader WebAssembly CG involvement. Done means the open questions have a documented, agreed process rather than an implementation patch.