The "ZonedDateTime.parse" may not accept the "UTC+XX" zone id

After integration of JDK-8236548 the next code stop working:

        ZoneId zid = ZoneId.of("UTC+01:30");

        String s = zid.toString() + " 2023-01-01 00:00:00";
        DateTimeFormatter FORMATTER;

        DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder();
        builder.appendZoneText(TextStyle.NARROW)
               .appendLiteral(" ")
               .append(DateTimeFormatter.ofPattern("uuuu-MM-dd"))
               .appendLiteral(" ")
               .append(DateTimeFormatter.ofPattern("HH:mm:ss"));

        FORMATTER = builder.toFormatter();
        ZonedDateTime.parse(s, FORMATTER);

The root cause is this line in that change:

https://github.com/openjdk/jdk/commit/5c3a01591c5c945926636fdc9f164d60b5b4f29e?diff=unified#diff-5fcf976db1c06e8f44a8671356d7e34fdfbf5b057baa852e7c3e015c8797c889R4263

Note that the comment said about French, but the "utc+" is ignored for all locales.

That fix had a CSR JDK-8238914, but I did not found there a reason why "utc+" was excluded, it is only mentioned as "Minor fix" here:
https://mail.openjdk.org/pipermail/core-libs-dev/2020-February/064683.html

So the change was done intentionally, but it seems it contradicts the specification of the "appendZoneText" method, which is used in the test above. In the test the "+utc" is accepted as zoneID but rejected during parsing, but the spec says:
============
During parsing, either the textual zone name, the zone ID or the offset
     * is accepted. Many textual zone names are not unique, such as CST can be
     * for both "Central Standard Time" and "China Standard Time". In this
     * situation, the zone id will be determined by the region information from
     * formatter's

https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/time/format/DateTimeFormatterBuilder.html#appendZoneText(java.time.format.TextStyle)

So the implementation should be aligned with the spec or the specification should be updated.