I would not generally think of it like this - in terms of platforms, and purely additive - but in terms of features. Rather I would think of it as "this is a crate that works without the windows/unix/threads/networking" scenarios. The "default" scenario, that all present (non-no-std?) crates are assumed to operate under is the "windows/unix/threads/networking" scenario. In the future there will be scenarios that subtract parts of std, and thus subtract parts of the std scenario. So the emscripten std would not declare support for any of the aforementioned scenarios. Any emscripten-supporting crates would need to declare they work without chunks of std, vaguelly like
#![scenario(core, collections, alloc, rand)] // For an additive declaration started from a position of "no-scenarios"
#![scenario(without(threads, networking))] // Declaring which features you can live without
In the subtractive case, the compiler won't let you build until you've subtracted all the parts that the emscripten port doesn't support. And you can imagine further declaring (somewhere) "I want to support this set of platforms", and have cargo/rustc tell you (without having actual cross-compile capability to that platform) "no, you are not in the right scenario, do these things to fix".
This ability to have the toolchain statically tell you which platforms you can support without actually attempting to compile I think is the thing we need out of scenarios. Otherwise it's just a reformulation of cfg.