I'm not going to comment on Khronos politics and I have almost no insight into Apple's future roadmap, but I will say that I would find it fairly shocking if they announced support for Vulkan any time in the next several years.
The memory model Vulkan exposes is simply not something we can do in the browser. That's not a subject that's up for debate, it's a fact. Therefore we can't do a 1:1 Vulkan mapping. Period. I don't feel that the memory model is a feature with the same level of significance as some of the other core concepts of the modern APIs (Command lists, etc.), though, and the web should be able to handle the rest of it just fine.
Yes. I told them that.
No, as I recall the context for that statement was that the Vulkan memory model was already pretty well decided on by that point. So when they began asking about whether or not other features should be tweaked with the web in mind my response was "We already know that we can't support the memory model directly, so whatever we eventually expose to the web won't be a 1:1 mapping of the API anyway. As such, please don't dumb it down for our sakes."
I can't really get sucked into a long email thread today, so let me make my position clear and then I'm gonna have to step away for a bit:
- Vulkan, for all it's complexities, is a great API. So are the other modern graphics APIs! I'm happy they exist.
- I don't think we need to protect developers from complexity. That's what Three.js and friends are for.
- I absolutely want to see modern API capabilities make it to the web in some form.
- That form will never be a 1:1 mapping of Vulkan, even if Apple supported it, because the memory model is not compatible with the web. Full stop.
- Apple has only committed to Metal and does not comment on future API support as a matter of policy. Since Metal represents a subset of Vulkan's features we have to plan on the web supporting that lowest common denominator of features until Apple states otherwise. This also prevents us from doing a 1:1 Vulkan mapping.
- Outside of those restrictions, I don't have super strong opinions about the exact form a modern GPU API for the web takes. I personally think it should be modeled after Vulkan but take advantage of being web-centric where reasonable. I'd also be fine with a straight C mapping that has the incompatible bits stripped out. I'd also be fine with something completely new, though I don't think the WebGL working group has the time, energy, or manpower for it.