This page is a compilation of formal public feedback received so far. See Feedback for further information on this issue, how to discuss it, and how to provide feedback.
The links below go to locations in this document for feedback.
Feedback routed to CJK & Unihan Working Group for evaluation [CJK]
Feedback routed to Script Encoding Working Group for evaluation [SEW]
Feedback routed to Properties & Algorithms Working Group for evaluation [PAG]
Feedback routed to Emoji Standard & Research Working Group for evaluation [ESR]
Feedback routed to Editorial Working Group for evaluation [EDC]
Feedback routed to Charts Working Group for evaluation [CHARTS]
Other Reports
(None at this time.)
Date/Time: Thu Oct 15 18:50:27 PT 2026
ReportID: ID20261015185027
Name: stasoid
Report Type: Report Error in Publication/Data
Opt Subject: Proposal to Reallocate the Quikscript Block to U+107D0..U+107FF
Document https://www.unicode.org/L2/L2026/26243-quikscript.pdf proposes to allocate Quikscript at U+16080. I propose to allocate it at U+107D0 instead to keep it close to Shavian. Comb. Diacritics Ext.-A can be moved to U+1E090 or dropped completely since some of those characters are already planned to be added to existing Latin blocks (see 1AF2, 1DF8B in the pipeline). The unallocated column at U+107C0 can be used to extend Latin Extended-F in the future if no better use for it is found.
Date/Time: Sat Oct 10 16:44:28 PT 2026
ReportID: ID20261010164428
Name: Oliver Kuederle
Report Type: Report Error in Publication/Data
Opt Subject: Wrong Result in Default Work_Break Test Case
The following document lists test cases for the Standard Annex #29 (Unicode Text Segmentation) Word Boundaries ruleset: https://www.unicode.org/Public/18.0.0/ucd/auxiliary/WordBreakTest.txt The following line in this file is not correct: ÷ 0061 ÷ 1F1E6 × 1F1E7 ÷ 1F1E8 × 1F1E9 ÷ 0062 ÷ # ÷ [1.0] LATIN SMALL LETTER A (ALettermExtPict) ÷ [999.0] REGIONAL INDICATOR SYMBOL LETTER A (RI) × [16.0] REGIONAL INDICATOR SYMBOL LETTER B (RI) ÷ [999.0] REGIONAL INDICATOR SYMBOL LETTER C (RI) × [16.0] REGIONAL INDICATOR SYMBOL LETTER D (RI) ÷ [999.0] LATIN SMALL LETTER B (ALettermExtPict) ÷ [2.0] While this test case does follow the Default Word Boundary Rules in isolation, Section 3 of the document explicitly states: Word boundaries, line boundaries, and sentence boundaries should not occur within a grapheme cluster: in other words, a grapheme cluster should be an atomic unit with respect to the process of determining these other boundaries. According to the Grapheme Cluster Boundary Rules, the sequence must not be broken between REGIONAL INDICATOR SYMBOL LETTER B (RI) and REGIONAL INDICATOR SYMBOL LETTER C (RI). Thus, there cannot be a word boundary between these two characters. It appears that with respect to the rule set forth in Section 3, there is a mismatch between Grapheme Cluster Boundary Rules and Word Boundary Rules.
Date/Time: Mon Oct 26 14:04:17 PT 2026
ReportID: ID20261026140417
Name: CEO M. Al-Hasoon
Report Type: Report Error in Publication/Data
Opt Subject: Unicode 17.0.0 / UTS #39 R32 — Skeleton Idempotenc
Issue Summary: Unicode 17.0.0 / UTS #39 Revision 32 — Confusable skeleton idempotence counterexamples I would like to report a reproducible discrepancy between the published Unicode 17.0.0 confusables data and the idempotence property described in Section 4 of UTS #39, Revision 32. Using the specified transformation: internalSkeleton(X) = NFD(prototypes(removeDefaultIgnorables(NFD(X)))) the following published mappings produce different results on successive applications: 321D ; 0028 C624 C804 0029 ; MA 11AB ; 1102 ; MA For input U+321D: First application: 0028 110B 1169 110C 1165 11AB 0029 Second application: 0028 110B 1169 110C 1165 1102 0029 The difference arises because the final NFD operation exposes U+11AB, which is mapped to U+1102 on the subsequent invocation. Independent implementations using the original Unicode 17.0.0 data reproduce five single-scalar idempotence counterexamples: U+01C4, U+01C5, U+01C6, U+048B, U+321D The original data files were verified against the published versioned sources. Could you clarify whether these results reflect an intended interpretation of the algorithm, a known data issue, or a discrepancy requiring an erratum or future correction? References: https://www.unicode.org/reports/tr39/tr39-32.html https://www.unicode.org/Public/security/17.0.0/confusables.txt Thank you for reviewing this report. UIC Lang
(None at this time.)
Date/Time: Wed Nov 04 09:48:02 PT 2026
ReportID: ID20261104094802
Name: David Corbett
Report Type: Report Error in Publication/Data
Opt Subject: Errors in the core spec about Duployan
The “Duployan” section mentions the languages “Lilooet, Shushwap, and North Thompson”. The first two language names are spelled “Lillooet” and “Shuswap”. The third language is just called “Thompson”; North Thompson is a location. Later, it mentions “The Romanian Pernin, Perrault, and Sloan stenographic orthographies”. A comma is missing: it should start “The Romanian, Pernin”. The “Shorthand Format Controls” section claims that “the overlapping behavior is limited to consonants, circle vowels, and orienting vowels overlapping consonants”. Those are certainly the most common, but pretty much anything can overlap anything. For example, https://archive.org/details/sfintescu-margareta-stenografie-fara-profesor/page/186/mode/1up shows K overlapping A in the abbreviation for “acest caz”.
Date/Time: Mon Oct 26 15:34:29 PT 2026
ReportID: ID20261026153429
Name: Malachy Fernandez
Report Type: Report Error in Publication/Data
Opt Subject: possible mistake on unicode 18.0 delta charts page
i think there is a mistake on the unicode 18.0 delta charts page. https://www.unicode.org/charts/PDF/Unicode-18.0/. the Character Additions table lists "Mathematical Alphanumeric Symbols* 1" in the new characters column. but the page also says "Blocks containing no new characters, but with significant glyph updates, significant metadata updates (for CJK ideographs), changes to standardized variation sequences, or new formal name aliases are highlighted in blue in the Glyph, Variation Sequence, and Name Alias Changes table." that second table lists 1D4CF for Mathematical Alphanumeric Symbols. i think it just got counted wrong in the first table and isn't actually a new character. There also might be an issue in the updated Mathematical Alphanumeric Symbols PDF, but i'm less confident in reading that (https://www.unicode.org/charts/PDF/Unicode-18.0/U180-1D400.pdf).
(None at this time.)