Should the C++ mapping document specify that @value annotations, if specified for one field, MUST be used on all fields.

The text:
"Inherits std::integral_constant<uint32_t, b> where b indicates
the bit_bound of the bitmask."

should instead state

Defines value - Where the value is mapped as the underlying bit_bound of the bit mask.

Can a default annotation be applied to string types (bounded and unbounded)?

What happens when the following is present in an IDL file:

typedef @min(2) @max(1) long Huh;

Prior to C++20, the following template cannot be instantiated:

template <typename T, const T thingy>
class MyTemplate {};

MyTemplate<double, 5.0> x;

For instance is this legal:

struct S

;

typedef @min(2) long MyMin;
typedef @max(5) MyMin MyMinMax;
typedef @default(3) MyMinMax defaultedMyMinMax;

Each annotation specified, either pre-defined or user-defined/custom, should discuss how it interacts with the IDL4 grammar such that the annotation has the desired effect (e.g. @range on a union).

Not sure where (not necessarily in the noted paragraph) should include a reference to an electronic mapping file as an example. Could also include test sample IDL and corresponding C++ output. This should probably be informational and could also be in an Annex. The key reason is to show the actual transformation as well as a test/verification of the mappings. Perhaps also include versions of tools/compiler used in which the transformations were validated. In addition unit tests could be referenced or included as informative content to the spec.

The @value annotation does not fully specify the behavior. That includes:

• The behavior for unannotated values.
• The behavior for repeated values. Is it possible like in C++?

DDS-XTYPES does specify the behavior of @value and such description should be added to IDL:

7.3.1.2.1.5 Enumerated Literal Values
Prior to this specification, it was impossible to indicate that objects of enumerated types could be stored using an integer size other than 32 bits. This specification uses the @bit_bound annotation defined in Sub Clause 8.3.4.1 of [IDL] for this purpose.

It is important to note that the value member of the annotation may take any value from 1 to 32, inclusive, when this annotation is applied to an enumerated type. Furthermore, prior to this specification, it was impossible to provide an explicit value for an enumerated literal. The value was always inferred based on the definition order of the literals. That behavior is still supported. However, additionally, this specification allows enumerated literals to be given explicit custom values, just as they can be in the C and C++ programming
languages. This can be done by means of the @value annotation defined in Sub Clause 8.3.1.5 of [IDL], which may be applied to individual literals.
It is permitted for some literals in an enumerated type to bear the @value annotation while others do not. In such cases, as in C and C++ enumerations, implicit values are assigned in a progression starting from the most-recently specified value (or an implicit value of zero for the first literal, if there is no previous specified value) and adding one with each successive literal.

According to IDL4, annotations like range need to specify the arguments that are set. However, in the example we include for the mapping of @range we don't specify min and max in the arguments.

We need to address that as follows:

struct StructureOfRangedValues {
    @range(min=-10, max=10) long x;
};

Keys of maps can be any IDL type. How should the generated C++ code support key comparison of any type?

The IDL 4 spec states the default bit_bound is 32 bits the C++ mapping document states:
IDL bitmask declarations shall be mapped to two C++ type names:

• An unscoped enum named <Bitmask>Bits with an explicitly defined underlying type. That underlying type
  is the smallest mapped unsigned integer type that has sufficient bits for the bit_bound of the bitmask:
  uint8_t, for values between 1 and 8; uint16_t for bit_bound values between 9 and 16; uint32_t, for
  values between 17 and 32; and uint64_t for values between 33 and 64. The <Bitmask>Bits enumerators
  are the values defined in the scope of the IDL bitmask, with each enumerator explicitly initialized to its
  corresponding integer value.