This was introduced in #119616 (cc @rylev)

Currently, any crate using std::os::wasi stuff needs to add a #![feature(wasip2)] if it is to be compiled with --target=wasm32-wasip2. This is due to this line:

This puts library authors targeting stable wasm stuff in an annoying situation of needing to add a feature gate to support downstream users who wish to use unstable wasm stuff (see servo/rust-url#960). This isn't really how feature gates should work: the entity using the feature should be the one opting in. I don't think any of the benefits of feature gates apply if every wasi-using dep in the ecosystem just slaps on a #![cfg_attr(all(target_os = "wasi", target_env = "p2"), feature(wasip2))], which seems likely here.

A somewhat legitimate reason I could see for having such a feature is if the wasip2 target is stable, but certain stdlib things are unstable under that target. It still has the same problems, and I'd argue a target with specially unstable stdlib APIs should not be considered stable, but at least there appears to be a meaningful thing that the stdlib feature gate is gating.

However, it appears to me that wasip2 is just unstable: what's the purpose of gating the stdlib API? If the goal is to gate the target, why not require -Zunstable-options as we do for other CLI-level unstable things?