No disagreement here! Just to contextualize: Docker — the company as it exists today — is singularly focused on the development experience, i.e. the inner loop of code/test/build, not the outer loop of deploying to production (which is largely controlled by cloud platforms and k8s at this point). I know that separation can seem arbitrary, considering containers are largely successful because they help bridge the two, but that’s just the reality of what we’re focused on in our daily jobs @ Docker.
Within that framework, we see Wasm as extremely compatible with our goals of improving the local development experience, and yes, giving people alternatives to container-centric approaches. I’m personally inclined to agree with the points you are making about opportunities in orchestration, but we’re starting today by just trying to give people to a solid toolset that lets you iterate on your Wasm apps locally, and easily export the resulting artifacts, so you can deploy them as you see fit. In the process we try to be careful about shedding any container-centric assumptions, while porting over some of the wins of the docker tooling that we think can translate well to Wasm (easy local dev environment, standard artifacts, broad platform compatibility across Windows/Linux/M1, etc.) We will happily work with anyone interested in working with us to improve the production/deployment landscape for Wasm, and in fact I would say the main reason that drove us to launch this technical preview today, was to attract feedback on how the Wasm community (ourselves included) could best deliver an alternative path to production for applications going forward.
Hope this makes sense and that I understood your point accurately!