Indeed, they are already doing it, we're lucky they weren't in a dominant position when TCP/IP or HTML were invented.
So actually the thing you're complaining about is prevented by ARM themselves; Apple cannot publicly commit to features that would fragment the architecture. They don't have to do everything identical either, though.
[1] They have publicly said they will allow some future Cortex cores to contain custom instructions, but it is quite clearly something they're very much still in control over, you won't get a blank check, especially considering almost all ARM licensees use pre-canned CPU cores and IP. You'll probably have to pay them for the extra design work. There are no known desktop/server-class CPUs that fit this profile on the current ARM roadmap, or any taped out processor, that I am aware of.
They would not use that naming if they intended to support the official ARM ISA in the long run.
The only thing that would prevent them for going the proprietary route is if they can't.
Given Apple's marketing priorities, my guess is that the intent you speak of had zero weight in their naming decisions either way. They have no interest in raising the profile of ARM chips in general, and every interest in promoting their specific chips as amazing.
The Scalable Matrix Extension supplement was released last year. Though obviously AMX predates it, having shipped in actual silicon 3 years ago.
Apple fronted the cash that created ARM holdings in the first place, so yes, they invested quite a lot of money (well, relative to the other senior partners Acorn and VLSI and later investors), and ARM was hardly in a position to tell them "no".
TCP/IP and HTML became dominant because they were open standards. Should they have been proprietary, they would have floundered and something else would have emerged instead.
When you have a long-running fork, especially one that is so active, merging it naturally becomes a nightmare. This is expected and ordinary.
The Linux kernel gets forked by Android vendors and others all the time. A lot of the changes never make it upstream, for various reasons. At least the story ends a bit better for KHTML / WebKit.
I'm beyond the point of negotiating with the people on this website. Apple is due in for exactly the same treatment, it's only a matter of time before the US eats their favorite crow.
But as an aside, don't let this site get to you too much. There's a lot of arguing for sport that goes on here.
I kinda doubt that. As soon as Microsoft had a virtual monopoly on the browser market, they let IE go stale for years. Hardly any feature development, hardly any bug squashing. Terrible security. By the time the browser choice thing in the EU and the antitrust thing in the US happened, the rot had already set in and everyone was fed up and yearning for a browser that didn't suck. Google drove their Chrome truck right into that gap.
If IE had actually been a decent browser, no amount of "choose your browser" screens would have been enough to sway people from it. Just like they cling to Chrome now because Google is too smart to make that mistake.
PS FWIW I don't like and hardly use chrome but technically as a browser it's great, I just don't like Google's attitude to privacy.
Anyone remember AppleTalk?
I am sure they will support open standards in time as they mature, but for now there is little advantage in doing so. Not to mention that open standards are far from being a universal panacea. Remember Apple’s last serious involvement into open standards - OpenCL - which was promptly killed by Nvidia. Apple has since learned their lesson and focus on their own needs and technology stack first.
What I liked about this is that Apple realized it makes more sense for someone other than them to develop and supply tech for something like Thunderbolt, co-engineered with Intel for Intel to do it (and eventually open it, royalty free).
But yeah it's ages ago and they've kept everything proprietary since then :(
In the recent years I am more and more convinced that open standards are not a panacea. It depends on the domain. For cutting edge specialized compute open standards may even be detrimental. I’d rather have vendor-specific low-level libraries that fully expose the hardware capabilities, with open standard APIs implemented on top of them.
Don't blame NVidia for AMD and Intel incompetence.
Ah, and on the mobile space, Google never supported OpenCL, rather coming up with their C99 Renderscript dialect.
Really, we've been lucky that it was Microsoft and not Apple that was the dominant player in the 90s.
And I am far from a Microsoft fanboy, but I think that Apple hubris has always been there, and their contribution have to be mitigated in some way to stay on the positive side.
Ironically what we see nowadays with phones, tablets and laptops is a return to those days of vertical integrated software.