Change in SimpleDateFormat parsing behavior for certain numeric tokens

Hi all, As described in a previous issue ICU-22179, there has been a change in a long-standing ICU behavior when using strict SimpleDateFormat to parse certain numeric tokens. The issue seems to be introduced in ICU71. The following tokens have changed their behavior - for parsing, they now require the numeric field to be at least the length of the token:

All the above-mentioned values used to be parsed successfully for the corresponding tokens before ICU71 but some of them now error. Note that other numeric tokens like MM, HH, yy, still follow the old rules and would accept a single-digit value in ICU71.

This issue was raised in ICU-22179 and we understand that it was mentioned that this is behaving as expected and "strict parsing should be strict". However, this behavior has been in ICU for years and we use ICU a lot for parsing and formatting dates and times. Over the years our users (and others as mentioned in ICU-22179) have started relying on this behavior. So it would be great if there was a way to preserve the old behavior, maybe through an explicit attribute, so that people who want the old behavior, for compatibility reasons, can still get it.

A couple of things that were suggested in ICU-22179 that do not help us address this issue:

1. Setting the calendar/formatter to lenient does not work for us, as it makes the formatter lenient for a bunch of other cases where we prefer strict behavior.

2. Another suggestion in ICU-22179 was to use one of the DateFormat.BooleanAttribute, however, none of the existing attributes provide a way to control this specific behavior.

3. Since this impacts existing code written by other users of our software, changing the format to d/M/u (and all the other impacted tokens) is not feasible.

The following cpp code successfully parses the string in ICU70 but fails starting ICU71: