So far, that whole endeavour made perfect sense to me, one small evolutionary improvement on top of another (even the switch from asm.js to wasm was evolutionary from the pov of the user, you just provided a different compiler switch, and you got wasm output instead of asm.js which ran at the same or slightly better speed).
WASI 0.1 was another evolutionary step that made total sense. It had a clear and simple mission: "provide a POSIX compatibility layer for WASM blobs". Very easy to communicate, very easy to use. You just write against (a subset of) the POSIX API and you get a WASM blob that runs on every WASM runtime that provides WASI compatibility, and providing full WASI compatibility wasn't all that hard, more or less just map to existing POSIX calls of the underlying platform.
But with WASI 0.2 I have for the very first time in 12 years the impression that the involved people are straying away from the successful evolutionary approach into architecture astronaut territory (and I have never seen that end well).
WASI 0.2 (0.3, etc...) should just be small improvements over WASI 0.1: better POSIX compatibility.
But with 'actual' WASI 0.2 I don't even know what it's supposed to be despite trying to keep up, it certainly can't be described in a single sentence except "it's awesome, just educate yourself!" - well I tried and I'm just as clueless as before. The problems it apparently wants to solve are nothing I care about (which isn't the case for WASI 0.1 which solves a very important problem for me).
What would be important to me in the near future is being able to run WASI 0.1 blobs on any popular desktop operating system without having to install a 3rd party runtime, a hard nut to crack of course because it requires getting Microsoft, Apple and probably even Linus on board - and the more complex WASI becomes, the less likely such a thing is.
Meanwhile, there's a real need to improve the POSIX compatibility of WASI 0.1 (for instance currently there's no concept of a current working directory for instance, but a lot of POSIX code depends on this).
Instead I get the impression that the WASI project has been hijacked and is being turned into something entirely different, with the original mission to provide a POSIX compatibility layer just being a little appendix that will soon be forgotten (apparently that appendix is now called 'wasi-libc').
I can only offer this advice: it would be better to take all the things that are not related to POSIX compatibility out of WASI and into a new project under a new name (maybe WASCOM or smth dunno...) and clearly mark that as "experimental". That would entirely avoid all the backlash and confusion you might currently be seeing, and probably also unblock 'actual' WASI progress (in the sense of improving POSIX compatibility).