Platform/system call level independence is usually referred to as
"system level portability", namely porting applications across
different OSs. This portability is different from previously mentioned
"CORBA application level portability", moving CORBA applications
acrossing forigen ORBs.

System level portability is not the task of CORBA, but a mission of
system level API standards or packages, such as POSIX (including
socket/winsock API, posix thread, etc.), or some portable
socket/network/thread classes/packages (there are too many such
libraries nowadays). Comparing to these portable system level APIs,
CORBA provides higher level abstraction. In these abstractions, objects
are system level entities, such as sockets (abstraction of network
endpoint) or socket classes, files (abstraction of device), shared
memory id (abstraction of shared memory sections), etc.. If you need
write system/network level applications, you should use a portable
system/network level library, but not CORBA.

Instead of providing a portable unification of system/network logic and
objects, CORBA hides these low level logic/objects/location on
performing distributed business level object invocations. OS level
details are transparent to business level applications, not mention
portability. CORBA Objects at this level are user defined, business
oriented objects.

I don't know too much about TAO and ACE, therefore, can't comment. But
AFAIK, almost all ORBs are built on an OS level portable layer, chosen
and usually implemented by vendor themselves. Vendors may or may not
expose/provide this layer along with their ORBs.

As said, CORBA is to HIDE OS level logic, therefore, application
PORTABILITY at this level is not a task of CORBA. Certainly, your
business level object implmentation (servant implementation) may use
system level logic, database logic, etc., but that is out side the
scope of CORBA.

Now, you come back to CORBA application portability acrossing foreign
ORBs. This is different from system level portability you mentioned
above. OMG has port many effort on this, including standardize client
and server side language mappings, POA and PI. Not standardizing header
file names (in C++ mapping), I guess, is merely to give flexability to
different ORBs, as well as to favor different application preferances.
As far as I know, most ORBs allow application developers to specify the
generated header file name prefix and extension, even the full name.

Regards,
Ke