Below I retranscript my questions, numbered 1 to 7, and either Eamonn's oral or written answer.
For some of them (#4, 6, 7), Eamonn's accepted to perform changes accordingly.

> [1] How is done the dot '.' handling by AttributeValueExp.getAttribute(javax.management.ObjectName) ?
> Corner cases like '.b' or 'a.' or even '.' are not detailed; the dot is "contained" whatever its location is.

[I retranscript our oral discussion here]
We agreed proposed spec should be left unchanged. Adding extra cases would make it heavier for little added value.
'.b' means an attribute named '.b' or the element b of the no name attribute; that latter case is strange but supported.
'.' means an attribute named '.' or the no name element of the no name attribute. That latter case should fail at runtime (JavaBean "get" doesn't define a noname element AFAIK). Case 'a.' is similar to that one.

> [2] What about deprecating the older way of doing queries ? Honestly if I'm a clean room implementor of JMX 2.0 I wouldn't want to spend time to support the old way: better go with the friendlier new one ONLY.

[I retranscript our oral discussion here]
No way. Deprecate means discourage use, not "there's a better way". And by the way, first we must keep compatibility, second the missing type safety of the SQL like way can be an issue for some users.

> [3] "The principal advantage of the method-chaining approach is that the compiler will check that the query makes sense. The principal advantage of the Query Language approach is that it is easier to write and especially read."
> What about specifying a method checkQuery(String):boolean that would return true is the query makes sense (is doable with method-chaining approach).

Most of the time you would just throw an exception if it returns false, and Query.fromString will do that anyway. Elsewhere in the platform where we parse stuff (Integer.parseInt, Pattern.compile) we don't have a separate method to test validity.

> [4] Wildcard use in SQL like queries
> "Message like 'OK: %'
>    Selects MBeans that have a Message attribute whose value is a string beginning with "OK: ". Notice that the wildcard characters are SQL's ones. In the query language, % means "any sequence of characters" and _ means "any single character". In the rest of the JMX API, these correspond to * and % respectively.
> like 'mydomain:*'
>    Selects MBeans whose ObjectName s have the domain mydomain."
>    ==> why not like 'mydomain:%' ?

Yeah, this is grotty. In Message like 'OK: %', Message is a string, and this is a classical SQL string match. In like 'mydomain:*', this is a test on the MBean itself, checking whether its ObjectName matches the given ObjectName pattern. It might be worth adding a note explaining this.

> [5] Am I right to say a sequence of N consecutive space characters is taken as a single space in SQL like queries ?

Yes. The text says "spaces can appear anywhere else", and does not limit it to single spaces, so I think this is covered.

> [6] In the SQL query grammar, predrhs doesn't speak to me (SQL lessons are far behind, I agree). What does it stand for ?

Perhaps "predrest" would be better.

> [7] Is it a valid query use case: like 'b//c//d:k=v'
> It would refer to MBeans like 'd:k=v' but registered in the MBS c itself registered in the MBS b.

It is allowed but will typically not work. We don't allow e.g. queryNames("*//*//*:*", q). You would have to write queryNames("b//c//*:*", q). Then q could be like 'd:k=v', because it is evaluated in the final MBS. This should be covered in the namespace documentation, and perhaps cross-referenced from here.