I understand the issue. Segmenter.java parses its UnicodeSets using IndexUnicodeProperties.make().getXSymbolTable(), which constructs a plain UnicodeProperty.MyXSymbolTable. That one implements a very minimalistic applyPropertyAlias, which does not support what I call a unary-query-expression in my draft specification. Worse, it fails silently (returning false), which means that we then use ICU properties. Thus \p{Extended_Pictographic} is computed by ICU, with 16.0 data.

For a binary-query-expression, the MyXSymbolTable works as intended and does not fall back to ICU, which is why \p{lb=HH} (which ICU would reject) worked fine in #1046.

The root cause is that there are no fewer than six class .* extends .*XSymbolTable in this codebase, which is around five too many. MySymbolTable in UnicodeSetUtilities.java is probably the least broken of the lot (I have been fixing some corners of it lately). See also:

• there can be only one UnicodeProperty.java #66
• There can only be one MySymbolTable #667

it fails silently (returning false), which means that we then use ICU properties

Probably stating the obvious:
In the context of the Unicode Tools, we should never "fall back" to ICU properties, especially not silently.
Use of ICU properties should be limited to consistency testing and comparison tools, if any.