The short: Yes, sadly(*), CORBA is outdated, as in:
- No decent
.NET
implementation
- The existing C++ binding is ugly, although there does exist a new C++11 binding
- No decent implementations for other modern languages (except Python)
That being said, existing CORBA implementations like omniORB, TAO, R2CORBA are supported and used, and are IMHO much more mature than many other IPC/RPC frameworks, although these are certainly more "modern" and are probably the future.
(*) I write sadly, and it is indeed a sad affair, because (point 3 from Q), there are quite a few frameworks rising, but there's not one that can fully replace it at the moment, and they all have problems of their own. (Immaturity, tailored for a narrow usecase set, interoperability (e.g. WCF via net.tcp), performance, footprint, licensing (ICE), ...)
Additionally, addressing point 2., while I do not agree with some points in The Rise and Fall of CORBA, one point that is indeed today a pain point is the lack of good versioning, quoting:
Versioning.
Deployed commercial software requires middleware that
allows for gradual upgrades of the software in a backward-compatible
way. CORBA does not provide any such versioning mechanism (other than
versioning by derivation, which is utterly inadequate). Instead,
versioning a CORBA application generally breaks the on-the-wire
contract between client and server. This forces all parts of a
deployed application to be replaced at once, which is typically
infeasible. (...)
While it is not as horrible as the paragraph makes it sound, it is an issue for which I do not know of an elegant solution, even when sticking to a single CORBA implementation for all your parts.