Should wasi:surface be split out into a separate proposal?

Having wasi:webgpu correspond directly to the existing WebGPU Web API makes a ton of sense. But the functionality in wasi:surface which includes the keyboard and mouse input is wayyy outside the scope of WebGPU. There are Web APIs for describing input sources, of course, and indeed wasi:surface/surface.key references https://w3c.github.io/uievents-code/#code-value-tables, but since input is defined by wholly separate APIs that are useful and usable independently of WebGPU, it seems like input functionality should be a separate proposal that is published, versioned and advanced separately from wasi:webgpu.

Incidentally, there have been a number of iterations on input on the Web Platform (indicating that it's a subtle and nuanced domain); see Pointer Events, Touch Events, Pointer Lock and the Keyboard API. Back when I worked on the Mozilla Games program, talking to gamedevs, some of these subtle API details mattered a lot, so I think it'd be a good idea to involve an expert in this area to help us scope out a proper "wasi:input" package and the set of Web APIs we should mirror into it. Or maybe there are other popular input APIs we should mirror that make more sense outside a browser? Inventing our own thing from scratch seems risky unless we have some significant input API expertise of our own. In any case, there will be some non-trivial design work, so it definitely seems appropriate to decouple from wasi:webgpu.

Start by reviewing the existing wasi:surface functionality described in this issue and the linked Pointer Events, Touch Events, Pointer Lock, and Keyboard API specifications. Determine the scope of a separate input proposal, which APIs it should mirror, and how it would be published, versioned, and advanced independently from wasi:webgpu.