Besides this approach being supportive of lock-in (of underlying closed APIs like Metal and DX), which is more than questionable, more importantly, what shading language should this Web API use for example?

Worth noting also that Khronos is considering a slightly higher-level API than Vulkan as their next iteration. So that's another reason it would be a shame to bind too tightly to Vulkan.

I also find it puzzling how designing to support multiple back ends is "lock-in" but binding tightly to only one underlying API is "open".

Lock-in refers to how that platform affects your options for deployment.

Openness refers to how that platform is being developed.

A platform can be designed in an open way, but if it only works in one environment (e.g. browser) you might consider that to be "locked in". As in, you are "locked" into using a browser for deploying your application.

Vulkan is open, in the sense that it is an open standard. It's managed in a way that allows a wide variety of people/companies to contribute to it's design and implementation.

Vulkan as an API is an abstract model for how a GPU works. Everyone codes to that spec, and they can work on a wide variety of systems. So you are not locked in to a limited set of systems.

In fact, if you wanted to make your own Vulkan implementation you could, and there is a lot of documentation, conformance tests, etc to help with that.

Supporting multiple backends naturally requires an abstract API on top to handle the inconsistencies in the underlying systems. A new API naturally means that existing code would need to be refactored to work with it. If that API only serves the purpose of executing within a specific context, you might consider that to be "lock-in" for that platform.

Maybe that will change, but blocking on a major new WebAssembly feature did not seem wise.