Mark:

I think the very best approach would be to remove UnicodeProperty from CLDR if possible. There are however lots of direct and indirect dependencies. Second best would be to merge anything useful from the unicodetools one into the CLDR one, and delete the unicodetools one.

Yes, all as discussed in the top description of issue #66.
And, as it says there, the unicodetools code has been running with the CLDR repo version which is newer and has more recent changes.

I agree with moving the unicodetools version to a different package, to avoid the shadowing, but I strongly suspect that the version there needs to be mostly a copy of the CLDR version, in order to preserve behavior.

Steven:

I'm not sure we've been using the CLDR version consistently. I think it may be hit or miss depending on how it is packaged or loaded.

My comment from last year says that the CLDR version has a different signature. Either the Unicode Tools rely on that now, or they don't call anything where the API has changed.

From #66:

Until 1.5 years ago they were identical, but they have been diverging and are now no longer even interface-compatible. The CLDR version is the newer one.

Looks good to me. A couple of questions.

Were the moved files like BagFormatter just copied, or were there more substantive changes?

The ones from CLDR that are completely new were not changed. I can enumerate.

Why was "final" removed from a number of declarations in unicodetools/src/main/java/org/unicode/jsp/UnicodeRegex.java? Was that because of merging with another version?

Merging between the unicodetools and the jsp version.