Its a mess right now, I agree. There is an almost anti-standardization mentality from the biggest organizations in all of this. The hardware diversity is adding to the complexity.

Since most of the language and software issues are based in the USA while the hardware is manufactured mostly elsewhere, how will DirectX 12 help the situation? Globalization seems to be forcing Microsoft to promote its own hardware, such as the Xbox series, mobiles, and hybrid laptop/tablets (don't know what to call the recent new genre ) as hardware platforms for its own software products.

My prediction is that Intel, NVidia, and AMD will create even more demand for Microsoft to develop its own hardware for its software, because of the anti-standardization trend. Perhaps DirectX 12 is a strategy by Microsoft to "clear the chalkboard" so to speak to prepare the way for more of their own hardware. I would not be surprised if Microsoft finds a way to put chips in their hardware which are specifically designed for DirectX 12 and later versions of DirectX, since the current chipset technology is a mess for game developers.

By contrast: Apple, AMD, Intel, NVidia, and other major players are diversifying themselves into an uncompetitive chaos, in my opinion, playing right into the strategy of Microsoft to build hardware for its own software.

Microsoft to promote its own hardware, such as the Xbox series, mobiles, and hybrid laptop/tablets (don't know what to call the recent new genre ) as hardware platforms for its own software products.
My prediction is that Intel, NVidia, and AMD will create even more demand for Microsoft to develop its own hardware for its software, because of the anti-standardization trend.

By contrast: Apple, AMD, Intel, NVidia, and other major players are diversifying themselves into an uncompetitive chaos, in my opinion, playing right into the strategy of Microsoft to build hardware for its own software.

Microsoft's hardware products use hardware that's manufactured by AMD, Intel, Qualcomm, etc, etc... They're still reliant on these hardware partners to implement D3D drivers (and processors) for them

That's the way it will be at least in most of Microsoft hardware for a long time to come, but I don't see why they could not order a chip made especially for DirectX 12 and APIs after that, for example, to be put into a future Xbox version.

but I don't see why they could not order a chip made especially for DirectX 12 and APIs after that, for example, to be put into a future Xbox version.

Because its a bad idea to put a general purpose API in a fixed platform for example? Putting PC oriented APIs in consoles is bad idea "If you had a proper specific API you could squeeze one year more out of that Xbox but nope! DirectX 12 for everyone!" Doesn't works like that. They're pretty much forced to make a specific API for the consoles lest the developers drop it before it reaches the expected EOL.

When a console is reaching its EOL, its a very fine balance between "Our next title will be on PC and we'll see how we can make Xbox version work." and "Only PC version, Xbox is too old to make the things we're going to do."

That's the way it will be at least in most of Microsoft hardware for a long time to come, but I don't see why they could not order a chip made especially for DirectX 12 and APIs after that, for example, to be put into a future Xbox version.

In the past we've had chips made especially for D3D 8, 9, 10 and 11. You may have heard of them: they were called "GeForce" and "Radeon".

I'm only being half-facetious here. The truth is that hardware is not as general as some APIs may give the impression of it being. Specific hardware generations have their own specific strengths and weaknesses, and something which was efficient in one hardware generation may be horriffically slow in the next. Typically a hardware generation is matched by a D3D revision, sometimes with the vendors driving the switchover, sometimes with Microsoft driving it, sometimes with both working together.

The truth is that hardware is not as general as some APIs may give the impression of it being.

The reverse is also true; the hardware looks nothing like the API claims it does.

Current DX11 API has a required VS->HS->[Tess]->DS->PS flow, but in reality there is no reason for that VS step.
There are also 'slots' for resources yet common hardware has, for the past few years now, not had 'slots' at all and things like texture data is looked up via a memory description.

Legacy is fun like that

Just a few tech generations ago, we could play some awesome OpenGL games that seemed to really rival Direct. Am I wrong to perceive a gap that is ever widening in actual end-user gaming results between OpenGL and Direct? As already touched on this area earlier in this thread, it might already be fundamentally too late for OpenGL to regain the glory that it once had. I am dumb struck at how Apple and others have let OpenGL go to waste.

On the other hand, my opinion is that Microsoft is very effective in promoting their market strategy. The performance and features are available and in general with excellent tech support for those willing and able to invest the capital. A few years ago I would see a little enthusiasm for the future of developing for Macs, but I think that Microsoft is winning the war of attrition.

Am I wrong to perceive a gap that is ever widening in actual end-user gaming results between OpenGL and Direct? As already touched on this area earlier in this thread, it might already be fundamentally too late for OpenGL to regain the glory that it once had. I am dumb struck at how Apple and others have let OpenGL go to waste.

That gap's been there for quite some time. It started with the eternity that it seemed to take for GL to get buffer objects (DX7 in 2000, GL_ARB_vertex_buffer_object approved by the ARB in 2003), then high-level shading, galloping through two complete failures to deliver a "more modern, more streamlined" API revision (via 2.0 and 3.0), and it's continuing today with the ARB's ongoing failure to address some long-standing API deficiencies (most notably the antiquated bind-to-modify paradigm which everybody hates).

It's not Apple, it's not Microsoft, and it's not the hardware vendors who have set back OpenGL - much of the blame can be laid squarely at the ARB.

That's unfortunate because despite all of this OpenGL still retains some nice features that don't exist in D3D. Immediate mode is great for rapid prototyping, for example, and the multi draw stuff is handy to avoid having to maintain a few dynamic buffers too, and they're just two simplistic examples off the top of my head.

In terms of visual quality both APIs can be considered identical. It's the hardware that does all the heavy work, after all. As soon as you get programmable shading you can do anything, so that's not a consideration (how efficiently you can do it is a consideration). What that means is that basic API quality is the deciding factor, and that's where GL has been falling behind.

It's not Apple, it's not Microsoft, and it's not the hardware vendors who have set back OpenGL - much of the blame can be laid squarely at the ARB.

This statement looks flawed to me.

"Its not Microsoft, nor Apple, nor nVidia, nor Intel, etc. Its the ARB's fault!"

Then tell me who is part of the ARB/Khronos Group? Apple, nVidia, Intel, AMD, Imagination Technologies and a big etc (Microsoft isn't part of Khronos, I'll give you that) I haven't seen them actively opposing OpenGL's direction at all (AFAIK all hardware vendors just try to justify ARB/Khronos decisions again and again).

If you're going to blame the ARB, then you are blaming all its members. The ARB isn't just some extraterrestrial thing, its composed by the entities you said they're devoid of responsibility concerning the state of OpenGL.

None. We are all moving to SteamOS.