It appears that javac doesn't handle type-variable substitution consistently when diamond oerator is used in conjunction with member classes. The problem lies in the fact that javac attributed a diamond AST node as follows:
new X<String>.new Y<>
[where Y is 'raw']
This leads to problem when the synthetic constructor is accessed as a member of X<String>.Y, as javac tries to replace formal type-vaiables (T,Z) with a set of actual arguments which is smaller (String). This lead to a bad substitution and to a spurious compiler error.
In order to guarantee better interoperability with type-variable substitution, the diamond AST node should be attributed as: