Running the tool just now gives me the same exception but for a different property:

Modifier_Combining_Mark	15.1.0.0
com.ibm.icu.util.ICUException: Modifier_Combining_Mark( from: /Volumes/Common/projects/unicode/unicodetools/unicodetools/data/ucd/15.1.0/PropList.txt)
	at org.unicode.props.IndexUnicodeProperties.load(IndexUnicodeProperties.java:492)
	at org.unicode.props.IndexUnicodeProperties.load(IndexUnicodeProperties.java:454)
	at org.unicode.propstest.CheckProperties.compare(CheckProperties.java:656)
	at org.unicode.propstest.CheckProperties.main(CheckProperties.java:219)
Caused by: org.unicode.props.UnicodePropertyException: Key already present in Map: Logical_Order_Exception,	old: 0000-0E3F=No
0E40-0E44=Yes
0E45-0EBF=No
0EC0-0EC4=Yes
0EC5-19B4=No
19B5-19B7=Yes
19B8-19B9=No
19BA=Yes
19BB-AAB4=No
AAB5-AAB6=Yes
AAB7-AAB8=No
AAB9=Yes
AABA=No
AABB-AABC=Yes
AABD-10FFFF=No
,	new: 
	at org.unicode.props.PropertyUtilities.putNew(PropertyUtilities.java:34)
	at org.unicode.props.PropertyParsingInfo.parseSourceFile(PropertyParsingInfo.java:501)
	at org.unicode.props.IndexUnicodeProperties.load(IndexUnicodeProperties.java:488)
	... 3 more

Thoughts from Markus:
CheckProperties seems to swallow the exception, and finishes with exit code 0. This could hide real problems.

CheckProperties was turned into a CI step by #253 for #187. But it was never written as a CI test; it was a tool you ran and whose output you read.

The documentation says

Run /unicodetools/org/unicode/propstest/CheckProperties.java to see what changed
and sanity check.

Fix any failures, such as: [an exception]

This means that we are not testing whatever was only tested by that, and I do not think we are manually running this tool and looking at its output anymore either.

And I think the validity of values in data files is one of those things; this would explain the Arabic_Tashkil problem noted by @jowilco.

Missing enum values are being caught by org.unicode.props.PropertyParsingInfo#checkEnum. The errors are stored in DATA_LOADING_ERRORS, but the only place that DATA_LOADING_ERRORS is being read is in CheckProperties.

Indeed.

Which would fail, if it were a thing that could fail. In fact it fails so much (because of unmaintained regexes) that the checkEnum failure isn’t actually printed (but it occurs, see the CI failure on the second commit in #1083).

What a mess.

I think we should change checkEnum to throw directly, and deal with the rest of the CheckProperties errors another day—the regexes are known to be out of date, for instance.

@jowilco, @markusicu, what do you think?

That works for me, but I'm not sure that I know enough to make the call.

I think we should change checkEnum to throw directly, and deal with the rest of the CheckProperties errors another day—the regexes are known to be out of date, for instance.

@jowilco, @markusicu, what do you think?

sgtm
changing checkEnum() to throw, and fixing what then fails, also sounds painful...

changing checkEnum() to throw, and fixing what then fails, also sounds painful...

It is not too bad for the current version.
On older versions it is a different story (today I learned about CCC=37 for U+0901 until Unicode 3.0…)

(today I learned about CCC=37 for U+0901 until Unicode 3.0…)

I got curious about that. That went away in Unicode 2.1.8:

• https://www.unicode.org/Public/2.1-Update2/UnicodeData-2.1.5.txt
• https://www.unicode.org/Public/2.1-Update3/UnicodeData-2.1.8.txt
• 1998-dec: https://www.unicode.org/history/publicationdates.html

In those days, many things about Unicode were not stable that have long since been stabilized. I believe Unicode normalization was stabilized in 3.0, modulo the NormalizationCorrections until 4.1 or so.