1. Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.
2. Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the 'simple' standard.
3. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.
To me, you're looking for ghosts when there are none. The Microsoft representatives stated multiple times on that thread that they fully agree the aliases for cURL and wget should be removed. They want to do an RFC to see how removing those aliases would affect existing scripts that use them. PowerShell has been around for a decade, it's more than reasonable to assume people have built workflows with those aliases.
Plus, step 3 literally makes no sense because these aliases only exist on the Windows implementation and everyone agrees they are substandard to the standard implementations.
But that won't prevent people from calling out EEE whenever Microsoft is involved.
How does this fit? The two Microsoft reps who post first say that the alias is wrong, and they'd like to remove it. I'd say that's the opposite of EEE, which would involve saying that you have to keep the Microsoft way.
Or they have realized that at this point they have to go back to the embracing state to compete with the Linux ecosystem. Hence all the Open Sourcing and the NT Linux subsystem.
That only fits if extinguish is still their eventual plan. Red Hat, Google, Amazon, even Apple all at some point embrace open source ideas/software/standards. Embracing is good. Extinguishing is bad. (Extending is...sometimes good, sometimes bad).
"Microsoft" is not some uniform entity. The people who perpetrated this mis-design aren't necessarily related to the decision makers who steered IE/Office/Windows to have the EEE behavior.
Not a uniform entity, but a real entity with real habits of behavior. You don't have to attribute any malice to the "people who perpetrated this mis-design", Microsoft's bureaucratic structure might just be designed in a way that EEE strategies arise organically. If they people who drove the use of that strategy with older software were rewarded, and held up as examples within the organization, their ideas could be permanently embeded in the nature of the organization itself.
My guess is that they wanted to keep onboarding easier for Linux types (Embrace) by creating an implementation they thought would handle the typical use case (like ls and the like) using a wrapper for their Invoke-WebRequest.
Unfortunately, they've now created a problem in that they need to modify things to prevent users of real curl from getting hosed but at the same time not breaking the Invoke-WebRequest wrapper.
But the goal of something like this may be no more nefarious than, say, Xamarin or similar where the goal is for reuse across systems.
Do we think Invoke-WebRequest is going to somehow become the new standard for curl functionality? Do we think Microsoft has any intention of that coming to fruition?
I imagine if they wanted curl for the sake of curl, they'd have included it (with attribution in some text file), and then parsed the results back into the object format preferred by PowerShell. Instead, it seems more like a stopgap to prevent people from having to totally rewrite their shell scripts to work in Windows as there was enough moaning over PowerShell at launch as yet another shell. Being completely incompatible with users potentially existing scripts? That'd be a big negative and honestly, a move the old Microsoft would've done without a doubt.
Personally, I'd prefer (and maybe it is this way, I don't use PowerShell) that if there is some type of text editor w/ Intellisense that if it saw a curl request it would give an error/warning (warning at the very least if you're going to do the alias thing) telling the user to read the Invoke-WebRequest API (and if it is something that they're currently mapping, offer replacing the curl statement with the IWR equivalent).
Seems the curl author's issue is primarily in that the alias created a situation where he receives false issue tickets (and don't get me wrong, that is terrible) due to the user thinking they're using curl when, in fact, they're not. And honestly, I could completely see where the user would be confused.
So back to the initial question, I don't see malice here. If they rewrote to include every piece of curl functionality and then went above that, then yeah, I'm with you. I do, however, see where someone screwed up royally (both in the initial shortsighted action and also in the headache it now creates for the PowerShell team in addressing w/o breaking for current users who knowingly/unknowingly are using the alias). I think that counts as stupidity.
This is of course their old and time-honored playbook, which served them well in the past, when they owned the PC market (literally).
But in the era of Linux, Google, and iOS, I don't think they have enough leverage to successfully implement the Extend. So they can forget the Extinguish.
That leaves only Embrace, which might work out best for all involved, a scenario wherein MS becomes a good neighbor in a diverse computing ecosystem.
In this case, nobody is going to keep using PowerShell on Linux or Mac if MS implements or promotes incompatible features. There is an exit available, where there wasn't on PCs in the 90s. I can go back to my plain old unix shell scripts, which have worked well for 30+ years.
To keep this project going, they are going to have to play nice and make sure it works well with everything. Or just abandon it. But they aren't going to be able to Extinguish anything, not in this day and age.
While I'm not sure I agree with you (this does not seem like it was done out of malice), I think it's interesting to note that MS employees probably need to be careful about adding fairly innocent changes/differences to popular APIs in order to avoid accusations of EEE.
If you want people to believe that this is a deliberate act to extinguish use of wget and curl, then I think you should explain what you think MS expects to gain from this. Why are they picking on two super-useful but comparatively specialised OSS tools? How much is the http data transfer tool business worth to Microsoft?
That's nothing more than old EEE strategy targeted for years against Unix/Linux. We will see this very soon again in Edge once its API becomes 'compatible' with Firefox and Chrome API for addons.
Seriously, how does this work in your mind? So Edge implements extensions the way Chrome and Firefox do, and the Microsoft tries to extend and extinguish it. Then what? People will suddenly not use Chrome or Firefox? EEE only works when people don't a reasonable choice.
To be fair, Firefox is planning on extending the chrome API for addons after (or really around the same time, in all likelihood) it reaches compatibility as well.
If it weren't, Firefox wouldn't realistically be able to deprecate XUL addons, because there would be no alternative for many of them.
To recap:
1. Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.
2. Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the 'simple' standard.
3. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.