CORBA25 — Local interface is-a Object?

For local interfaces, we seem to have internal inconsistencies in the spec.
For one, it is not clear whether or not a local interface implicitly inherits
from Object. There is one sentence in the spec that seems to imply that
there is implicit inheritance from object, on page 3-23 of the 2.5 draft
(http://doc.omg.org/ptc/1-6-10):

Any attempt to marshal a local object, such as via an unconstrained
base interface, as an Object, or as the contents of an any, or to
pass a local object to ORB::object_to_string, shall result in a
MARSHAL system exception with OMG minor code 4.

This implies that I can at least try to pass local object as CORBA::Object,
which implies that local interfaces do indeed implicitly inherit from Object.

But then, a bit further down, it says:

The is_a, get_interface, get_domain_managers, get_policy,
get_client_policy, set_policy_overrides, get_policy_overrides, and
validate_connection pseudo-operations, and any DII support
pseudo-operations, may result in a NO_IMPLEMENT system exception
with minor code 3 when invoked on a reference to a local object.

"May result in a NO_IMPLEMENT system exception"? I would suggest "shall"!

But, more seriously, I can't call is_a() on a local interface. In turn,
that seems to imply that I can't narrow a local interface either, but
narrowing is clearly necessary in the presence of inheritance for local
interfaces.

It seems that local interfaces must inherit from Object. After all,
it would be difficult to see, for example, how resolve_initial_references
can return a reference to the Root POA if it were otherwise... But then,
if local interfaces do inherit from Object, It doesn't make sense to
prohibit calling is_a() on them.

Related to that then is the question of "What is the repository ID of
a local interface?" Given that they can be narrowed, it would seem that
they must have repository IDs. (Although, you could argue that narrowing
is to be achieved via some mechanism other than repository IDs – that
would also permit is_a() not to be supported and would make narrowing
an issue that is specific to each language mapping.)

But the inheritance issue seems serious – if something doesn't inherit
from Object, I can't return or pass it as an Object, but we are doing
just that for local objects.

I think this will require some careful thought. We don't want to find
ourselves in yet another maze of twisty little passages, all different,
as we did with pseudo-objects...

Incorporate changes and close issue