Be's use of C++ (at the kernel/library API/ABI level) would have doomed it in the long term IMHO. There have been several incompatible C++ ABI bumps since then, all of which would have broken compatibility. See the current Be clones which still have to use an ancient version of GCC to not break compatibility with existing software.
NeXT's ABI interfaces (C and ObjC) were and are much more stable.
(I'm not saying don't use C++, just don't use C++ and expect a stable binary API. You need to wrap it in a C API instead unfortunately. There's too much magic in C++ to have a stable ABI and still be able to evolve the language.)
You're missing the point. The problem isn't using C++ internally in the OS -- it's exposing public C++ APIs. Because there's no stable ABI, that creates a dependency on the specific compiler.
That's exactly what happened to BeOS and Symbian. Both were stuck at GCC 2.95 for many years after mainline GCC was already at version 4.x.
There's a ton of C++ in macOS/iOS, but it's wrapped to plain C for the public userland APIs.
Symbian wasn't dead in 2007. It was the world's leading smartphone OS and shipped in tens of millions of devices yearly.
Symbian's inability to upgrade the platform to modern compilers definitely was one factor in its failure to gain developer mindshare, and the C++ ABI was the reason for that. They had painted themselves into a corner with a '90s C++ embedded dialect and had no easy way forward.
I'm curious -- which modern OS exposes a C++ API and is "doing pretty ok"? I can't think of any.
No, but no serious OS company migrates to a 4.0 compiler just when it gets released, rather a few years later when it has been proven in the field, by then it was too late.
Migrating to a new C++ ABI wasn't in any way related to Symbians downfall, internal politics were.
As for OSes ARM mbed, Windows all new APIs since Vista are based on COM specially anything UWP related, GenodeOS, Arduino bare-metal libs, IncludeOS.
"Unlike C++, COM provides a stable application binary interface (ABI) that does not change between compiler releases.[3] This makes COM interfaces attractive for object-oriented C++ libraries that are to be used by clients compiled using different compiler versions."
The others seem to be mostly embedded kernels or unikernels which will be tightly linked into your code anyway, so there's no issue of ABI incompatibility with those.
There is no such thing as Language X ABI, rather OS ABI or compiler ABIs.
COM is built on top of C++ VTBL implementation on Windows, UWP extends COM by supporting generics as well.
As for the other OSes, it is irrelevant where they are used, the fact is that they are exposing C++ APIs not C ones.
As matter of fact, had GNU/Linux not taken over the OS world and FOSS projects, and C would be pretty much history by now.
Mac OS, BeOS, Symbian, OS/2, Windows were all adopting C++ APIs when GNU/Linux started to gain adoption, with its manifesto to focus on C for GNU software.
This is a great point. I understand why a C++ ABI is so hard to keep nailed down, but the inability to do so has really hampered adoption of C++ as a true “system” language.
The first two are not really OSes and don't offer binary compatibility (they require recompile-the-world). And Symbian is dead, perhaps partly due to C++'s brittleness.
NeXT's ABI interfaces (C and ObjC) were and are much more stable.
(I'm not saying don't use C++, just don't use C++ and expect a stable binary API. You need to wrap it in a C API instead unfortunately. There's too much magic in C++ to have a stable ABI and still be able to evolve the language.)