Not exactly. It depends on what/where/how the system functions are
used. If used for delivering CORBA object invocations or to performing
CORBA services/features (such as calling functions of ORB, POA or PI),
they are transparent to CORBA applications, and inherently, the system
portability issue has been addressed already. If used to implement
client logic or servant logic, then, they are out of the scope of
CORBA, and their portability is not an issue of CORBA.

Unlike Java, .NET, etc,. CORBA itself is not "yet another uniform"
programming environment/platform, but a "middleware" infrastructure
to "mediate" business logics  distributed over heterogeneous
environments.

Firstly, there had been many attempts to standardize portable OS
interfaces in history, seen in the efforts of UI (unix international),
POSIX, OSF and X/Open (the two are now OpenGroup), etc.. Attempts of
having similar thing crossing unix and windows are not rare either,
including POSIX API (or its C++ variant) on Windows, WIN32 API or MFC
for unix, and so on, not mention open source contribution from GNU and
others. OMG is only one middleware standard body (certainly, OMG also
has many service and domain specific standards and MDA). To standardize
portable OS interface, OMG has almost no influence and zero credit
comparing to OpenGroup, ISO, IEEE and even ANSI, etc.. Therefore, even
if people wanted to reinvent-the-wheel, OMG is not the right
organization to head this effort.

Secondly, it is easy to construct a portable OS layer which covers
selected system functions enough to implement a few specific ORBs and
applications. NEVERTHELESS, contrary to what you thought, it is
non-trivial at all to generalize this, by extending CORBA, to an
universal portable application programming platform. If it was as easy
and useful as you thought, why it hasn't been addressed for years,
and has to wait  the hero OMG, who was said to out smart OpenGroup,
ISO, IEEE, ANSI folks just because who happen to have a magic thing
called CORBA? Even if excluded database and message middleware
abstractions and so on, and only limited this portable layer to cover
OS system functions, it would still not be a trivial undertaking to
have most mainstream flavor unix, windows and various RTOS (not merely
socket and thread parts) covered by one Swiss army knife which could be
reasonably function complete (not merely a small common subset),
efficient (it is no than an impl. issue!!), scaleable (in sense of
dynamic and static), consistent, extendable, intuitive and clear-cut,
... and so on.  Some of the above requirements are even mutual
exclusive. For instance, function complete (even if not 100%),
simplicity, lightweight and efficient together may prohibit
portability.

Thirdly, extending CORBA specification (or some other OMG
specifications) to based on a language (C++) specific design would
immediately bring damages to the consistency of the CORBA architecture,
such as language neutral and consistent memory management rule defined
by IDL-to-C++ mapping. An alternative is using local object IDL to
define such abstraction. Nevertheless, even if it could be accepted
outside OMG community, it was likely to have performance penalty, as a
lesson we have learnt from portable interceptor. Again, pls consider,
if we could easily and consistently extend CORBA or another OMG
specifications to include what you suggested, why would it wasn't
there in the original OMA or CORBA architecture? We are out smart our
OMG initiators?

As I said, it was my GUESS. I don't assume I am out smart those folks
defined the C++ mapping, and would like to GUESS their original
consideration of not specifying this. Pls think about non-trivial
cases. For instance, how would the specification avoid generated head
file names to conflict with existing system and library header files.
How would the specification ensure the generated header file name and
extension name are valid on all mainstream platforms (some platforms
have strict name length limitation). What would be the best practice to
partition generated content in header files (e.g. all in one jumbo
header file, or partitioned to multiple header files). If an IDL file
includes other IDL files, should one jumbo header file be generated, or
one (or multiple) header file(s) for each of the original and included
IDL files?

Regards,
Ke