Or the "Metro" versus "Classic Desktop" duality, where you had two versions of each builtin app. Some documents/links inexplicably opened in one version and other things in the other. Some dialogs used the classic UI while others used Metro. Some system preferences used the new fullscreen UI subsystem while others opened in the legacy Windows 95'ish panels..and they linked to each other! (like desktop resolution/monitor settings.)
I recall an instance where I could not copy/paste a password for a VPN service, because the password field appeared in a Metro-based sidebar overlay on the "classic" desktop, that collapsed itself when I clicked on a classic window.... Of course Metro was thankfully disowned by subsequent Windows releases as well, but it's still a cautionary tale of Microsoft's indecisiveness and Lovecraftian UI horrors.
Or earlier situations like when they cannibalized DirectInput in favor of the dumbed-down XInput API, dropping advanced features for force-feedback joysticks.
Or when you could not get great DirectX performance or access all of its features from within .NET for quite a while.
WPF was not used by Microsoft themselves in their own products as much as its adopters hoped, either.
Whereas on the other side of the fence, Apple has already been using Swift in quite a few user-facing areas of their products, and their latest graphics tech was fully usable from their latest language since Day 1.
While C++ is the language to go for device drivers and Metal shaders.
So there are still a couple of Swift free zones as of today.
I can list similar stuff being left behing by Apple, or even link that Java ONE video with Steve Job talking about Java going to be Mac OS X "Swift".
This at least should receive some improvement in the form of the new Swift-based Accelerate APIs:
I could still make an application with MFC, if I felt particularly masochistic. Carbon on the other hand…