DDSXTY14 — Unknown behavior of explicitly negated key in nested struct

In section 7.6.8 it is stated that for a nested struct that is annotated as key for an embedding struct, you have to follow the following process to to generate its KeyHolder: "If there are any key members, then remove the non-key members from FooKeyHolder. Otherwise do not remove any members."

So what if the struct has no explicit key members, but it has explicitly mentioned that a certain field should not act as key? Take for example the following example:

struct Foo {
    long x;
    @key(false) long y;
};

struct Bar {
    @key Foo myFoo;
    string name;
};

There are three different ways to interpret the rules for this usecase:

1. Both x and y will end up in the KeyHolder, since Foo did not specify any key members, so nothing gets removed.
2. Only y will end up in the KeyHolder, since Foo specified explicitly that x should not act as key.
3. Neither x nor y will end up in the KeyHolder, since some of the members have an explicit key annotation and so I remove all the members which are not keys, which is y (stated explicitly) and x (stated implicitly).

So the big underlying question is: is explicitly stating @key(false) equal to not having a @key annotation at all, or does explicitly stating that a member is not a key have some more expressive power over implicitly determining its key status by absence of the @key annotation?

Clarify what determines a keyed type and the members used to construct the key

Clarify how keyed types are defined in a manner that is consistent with DDS 1.5 and RTPS 2.5
Clarify which members are considered part of the key for the type
Clarify which member types can be designated as key (merged issue /DDSXTY14-45)
Clarify the IDL and XML syntax used to identify mey members and the meaning of designating a member wtth @key(false) in IDL and key="false" in XML.