The question is why Apple can't support Vulkan, or rather why wouldn't they. The answer is quite obvious - they like lock-in.
> If the Flowchart is true
Flowchart is not true, because using OpenGL is not a good proposition going forward. Some will develop more tools and higher level frameworks to make using Vulkan easier. But jerks like Apple, MS and others will put roadblocks for developers preventing them from using the new API on their platforms.
Because it's inherently stuck in the outdated model of using huge state machine where state is shared. It doesn't allow using parallelism efficiently.
> Khronos has publicly stated that development of OpenGL will continue
They are free to continue it, but I don't see a benefit of using it instead of Vulkan for anything new. The main drawback of Vulkan now is that it's low level in comparison with OpenGL. That gap will be filled in with frameworks on top of Vulkan which will provide higher level abstractions implementing a lot of common boilerplate while using Vulkan's approach of avoiding massive state machines. And those who need that low level directly can always go there. So why would you use OpenGL exactly?
This is kind of turning into FUD, the problem with OpenGL is not state - that is the problem with DX11, but for OpenGL we have AZDO in theory and properly implemented you should not see more stateful overhead comparing a Vulkan vs AZDO program.
The problem with OpenGL is that despite the official version being 4.5, and that including all the useful mechanisms to reduce overhead and make your renderer CPU efficient, only AMD and Nvidia proprietary drivers on Windows and Linux support it - which means you cannot realistically actually use it without having the same "minimum version renderer with extensions for optimization and features" model that makes writing OpenGL programs literal hell.
The point of Vulkan is less "fix a fundamental flaw in the efficiency of the OpenGL API as it exists" and more a "fix a fundamental flaw that hardware vendors don't write working OpenGL drivers that support the standard and stay up to date".
It's not a FUD. OpenGL was strongly overdue to be redone from scratch completely, and it's just great that Vulkan eventually was born from this necessity.
> The point of Vulkan is less "fix a fundamental flaw in the efficiency of the OpenGL API as it exists" and more a "fix a fundamental flaw that hardware vendors don't write working OpenGL drivers that support the standard and stay up to date".
It's both. AZDO attempted to fix serious deficiencies of the API without rewriting if from scratch, making it a rather awkward and not easy to use addition. Vulkan solved the same problem building it neatly from the ground up.
And of course making compliant and verifiable implementations is a great benefit of Vulkan, and it's something that OpenGL always lacked.
Because I care about working on phones, and on crappy old video cards and iOS and OSX.
Because the only times Vulkan provides any benefit over OpenGL is when I'm CPU bound, and that only happens on high end video cards, which are handling my workload without a sweat, so why would I bother optimizing those?
Because Vulkan is a low level API that's not easy to program for. OpenGL isn't exactly easy to use, but it's a heck of a lot easier than Vulkan, from what I can tell.
Because the work I do is more closely related to the CAD market than the video game market, and I know that there's enough money in CAD, and that OpenGL is not going anywhere for CAD, so I'd bet that OpenGL will be around for ~25 years in some form or another. I wouldn't place that bet on Vulkan.
> Because I care about working on phones, and on crappy old video cards and iOS and OSX.
Sure, OpenGL will remain useful for supporting both legacy applications and legacy hardware.
> Because Vulkan is a low level API that's not easy to program for. OpenGL isn't exactly easy to use, but it's a heck of a lot easier than Vulkan, from what I can tell.
I answered that above. It's not a reason to use OpenGL, it's a reason to write something on top of Vulkan to make things easier.
> Because the only times Vulkan provides any benefit over OpenGL is when I'm CPU bound
It provides a benefit of using your hardware to full potential. You can't even properly saturate the GPU with OpenGL with parallel workload, unless you use AZDO and other such things which turn it inside out trying to bypass its limitations.
> Because the work I do is more closely related to the CAD market
And why exactly Vulkan can't be used in the CAD market?
More likely, they committed to Mantle and now they have have to maintain it. The manpower to maintain 3 separate graphics back ends probably wasn't worth it, especially since big portions of the OS libraries now support metal.
My first thought on seeing Vulkan is that it is basically Metal for everyone else. Is that not so? Then why would you expect Apple to support Vulkan given that they already have Metal?
It's like saying that Apple shouldn't support JavaScript in the browser and should use AppleScript or anything else as long as it's incompatible (remember browser wars?). Why they should use it is quite straightforward - because it reduces duplication of work. Why they don't use it is clear as well - because they want to tax cross platform development with that extra burden. I.e. they use development tools as lock-in tactic. That's simply crooked.
Some history can also help. It all started from Mantle. Basically AMD grew tired of current APIs being behind the curve, and designed one from scratch that matches modern hardware approaches. Then Apple and MS used those ideas to push their lock-in off-shoots (they copied most of the ideas verbatim, working closely with AMD). Meanwhile, AMD simply opened up Mantle (they voiced this intention from the beginning) and gave it to Khronos as an initial proposal for Vulkan. The rest you probably know. So why exactly MS and Apple didn't get behind the shared effort? Because they are lock-in jerks. That's all there is to it.
The question is why Apple can't support Vulkan, or rather why wouldn't they. The answer is quite obvious - they like lock-in.
> If the Flowchart is true
Flowchart is not true, because using OpenGL is not a good proposition going forward. Some will develop more tools and higher level frameworks to make using Vulkan easier. But jerks like Apple, MS and others will put roadblocks for developers preventing them from using the new API on their platforms.