Mismatch between the Spin WIT and the effective Spin world

As part of the target environment validation project, I try to validate that (componentised and resolved) Wasm components conform to one of the supported Spin worlds for their trigger. For example, a HTTP component should conform to fermyon:spin/http-trigger@2.0.0 (https://github.com/fermyon/spin/blob/3e62d2e358d2aaa66563e55cffdad5ecd5dc0f4d/wit/world.wit#L4) or fermyon:spin/http-trigger-rc20231018@2.0.0 (https://github.com/fermyon/spin/blob/3e62d2e358d2aaa66563e55cffdad5ecd5dc0f4d/wit/world.wit#L10).

However, the fileserver 0.3 component (built with Spin SDK 2.x) does not conform to either of these worlds, because (again, once componentised) it exports wasi:http/incoming-handler@0.2.0-rc-2023-10-18 (which is available only in the fermyon:spin/http-trigger-rc20231018@2.0.0 world), but imports wasi:filesystem/types@0.2.0 and other WASI 0.2 interfaces (which are only available in the fermyon:spin/http-trigger@2.0.0 world). This is possibly an artefact of spin-componentize producing a hybrid, I am not sure.

Whatever the cause, the upshot is that attempting to validate the fileserver against either of the Spin HTTP worlds fails. If we implemented target validation using the current worlds, we would be telling people that the fileserver doesn't work. Which it does. Like a boss.

So, since this hybrid works, should the Spin world reflect that? That is, should the rc world import WASI 0.2 as well as WASI rc, and should the 'release' world import WASI rc as well as WASI 0.2?

Or is it correct that a component should fit entirely within one of these worlds, and this is merely a componentisation glitch with RC modules?

Additional context

The fileserver world before componentisation:

$ wasm-tools component wit spin_static_fs.wasm
package root:root;

world root {
  import wasi:io/poll@0.2.0-rc-2023-10-18;
  import wasi:io/streams@0.2.0-rc-2023-10-18;
  import wasi:http/types@0.2.0-rc-2023-10-18;
  import wasi:http/outgoing-handler@0.2.0-rc-2023-10-18;
  import fermyon:spin/llm@2.0.0;
  import fermyon:spin/redis@2.0.0;
  import fermyon:spin/rdbms-types@2.0.0;
  import fermyon:spin/postgres@2.0.0;
  import fermyon:spin/mysql@2.0.0;
  import fermyon:spin/sqlite@2.0.0;
  import fermyon:spin/key-value@2.0.0;
  import fermyon:spin/variables@2.0.0;

  export wasi:http/incoming-handler@0.2.0-rc-2023-10-18;
}

This appears to conform to the rc world.

The fileserver world after componentisation:

$ wasm-tools component wit COMPY-assets.wasm
package root:component;

world root {
  import wasi:io/poll@0.2.0-rc-2023-10-18;
  import wasi:io/streams@0.2.0-rc-2023-10-18;
  import wasi:http/types@0.2.0-rc-2023-10-18;
  import wasi:cli/environment@0.2.0;
  import wasi:cli/exit@0.2.0;
  import wasi:io/error@0.2.0;
  import wasi:io/streams@0.2.0;
  import wasi:cli/stdin@0.2.0;
  import wasi:cli/stdout@0.2.0;
  import wasi:cli/stderr@0.2.0;
  import wasi:cli/terminal-input@0.2.0;
  import wasi:cli/terminal-output@0.2.0;
  import wasi:cli/terminal-stdin@0.2.0;
  import wasi:cli/terminal-stdout@0.2.0;
  import wasi:cli/terminal-stderr@0.2.0;
  import wasi:clocks/wall-clock@0.2.0;
  import wasi:filesystem/types@0.2.0;
  import wasi:filesystem/preopens@0.2.0;

  export wasi:http/incoming-handler@0.2.0-rc-2023-10-18;
}

This appears to require imports from both worlds (which works, but does not conform to either WIT).

cc @tschneidereit

Start with wit/world.wit and compare the supported HTTP worlds against the before- and after-componentisation output from wasm-tools component wit for the fileserver 0.3 component. Trace how spin-componentize introduces the additional WASI 0.2 imports, then establish whether target validation or the Spin worlds should account for this hybrid; done requires an agreed compatibility outcome and corresponding validation behavior.