The current mandatory annotation definitions (7.4.15.4.1) will cause problems when IDL specifications are attempted to be reused between profiles applying different requirements concerning annotations (for example a profile with annotations and a profile without annotations or two or more profiles with different sets of annotations).

As the IDL 4 specification has removed the support for the commented form of annotations there is no possibility anymore to declare annotations in a form that has semantic meaning in one profile and does not cause parsing errors in another profile not supporting (these) annotations.
Even with the commented form supported the mandatory specification of annotation definitions for applied annotations would cause similar kind of problems as it is likely that the definitions for the standard set of annotations from one profile would not be available in another profile not supporting those annotations.

Personally I do not see any use for annotation definitions (and in fact I cannot find any commentaries regarding that in the spec) but I would suggest that at the very least IDL compilers should be allowed to ignore any annotations not known to the profile for which the IDL compiler is configured.
Ideally I would like to see a specification without any mandatory annotation definitions leaving it up to the tool supplier to enforce annotation definitions or implement implicit (embedded) definitions.

We would like to add a request to add the following IDL type. Just add a sequence of CCMHome typedef sequence<CCMHome> CCMHomes;

16.10 lists register_initial_reference. It would be usefull for dynamic systems to also have a unregister_initial_reference (in ObjectId id).

For several cases it would be helpful to have a:

Policy create_policy(
in PolicyType type) raises(PolicyError);

The name of the method has to change, to not conflict with the existing method

The context has to be define as local interface instead of a regular interface

The rule number (85) is indented, the rule number is not aligned with other rule numbers.

Is:
A character literal is one or more characters enclosed in single quotes, as in ’x.’
Should be:
A character literal is one or more characters enclosed in single quotes, as in 'x'.

(note that the present version uses curly quotes and the dot is probably misplaced)

The document title in PDF metadata
is "untitled",
should be
"Common Object Request Broker Architecture (CORBA)
Specification"

There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle. Having multiplex publisher port it would be easier to connect with dynamically created event consumers such that each consumer would have its own private communication channel with the publisher. In case of dynamically created consumers it is not possible to foresee the number of publisher ports required. For synchronous communication the elegant solution is a component with a multiplex receptacle for which we have separate communication channels.

The MIOP does not provide an analogous operation to PortableServer::POA::create_POA() for the GOA (i.e. there is no PortableGroup::GOA::create_GOA). The lack of an operation of this nature prevents the ability for an interface (i.e. servant) to subscribe to multiple (i.e. more than one) multicast group. To specify to a POA to allow multiple entries in its Active Object Map, the POAs IdUniquenessPolicy would have to be set to MULTIPLE_ID. This can only be done via the POAs create_POA operation. Since there is no GOA create_GOA operation, a GOAs IdUniquenessPolicy cannot be set to MULTIPLE_ID, which prevents a servant from being able to be subscribed to more than one multicast group. I don't know if the OMG explicitly wants to prevent this capability, thus purposely leaving it out of the MIOP specification, or if this is simply an overlooked issue.

The CORBA/e FTF slightly changed the definition of Invalid Policies to: exception InvalidPolicies

; since this avoids the use of an anonymous sequence type, consider changing it (also for consistency).

CORBA/e FTF (issue 11331): removed mention of (deprecated) function get_implementation from text. Consider making same change for consistency

There are two typo's in section A.4 on page 495.
1
SERVENT_RETENTION_POLICY_ID should be SERVANT_RETENTION_POLICY_ID
2
PortableServer::ServentRetentionPolicy should be PortableServer::ServantRetentionPolicy