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
Date/Time: Sun June 14 09:24:09 PT 2026
ReportID: ID20260614092409
Name: Ken Lunde
Report Type: Report Error in Publication/Data
Opt Subject: IDSes in UAX #45
The following UAX #45 records should be changed to add or update their IDSes from: UTC-00970;ExtG;U+30008;1.4;;;UTCDoc L2/12-333 2;;5;1 UTC-01044;ExtG;U+30AB1;119.5;;⿰米？;UTCDoc L2/12-333 76;;11;1 UK-01462;ExtB;U+24261;86.7;;⿱凹？;UTCDoc L2/15-260 150;;11;2 UK-01653;ExtG;U+30DCD;154.11;;⿱？貝;UTCDoc L2/15-260 341;;18;1 to: UTC-00970;ExtG;U+30008;1.4;;⿱𰀁龴;UTCDoc L2/12-333 2;;5;1 UTC-01044;ExtG;U+30AB1;119.5;;⿰米𰀈;UTCDoc L2/12-333 76;;11;1 UK-01462;ExtB;U+24261;86.7;;⿱凹⿹勹灬;UTCDoc L2/15-260 150;;11;2 UK-01653;ExtG;U+30DCD;154.11;;⿱𫻶貝;UTCDoc L2/15-260 341;;18;1 That is all.
Date/Time: Thu April 16 07:05:31 PT 2026
ReportID: ID20260416070531
Name: Sridatta A
Report Type: Report Error in Publication/Data
Opt Subject: Updates to Core Specification Chapter 6.1
In chapter 6.1 Writing Systems, under Abugidas Chapter 6 – Unicode 17.0.0 The various encoding models for Abugidas/ Indic scripts are described. "Because of legacy practice, three distinct approaches have been taken in the Unicode Standard for the encoding of abugidas: the Devanagari model, the Tibetan model, and the Thai model. The Devanagari model, used for most abugidas, represents text in primarily phonetic order and encodes a virama character that can combine with adjacent consonants to create conjunct forms. The Tibetan model also uses the primarily phonetic order, but its subjoined consonants are encoded directly rather than as virama-consonant sequences. The Thai model represents text in primarily visual display order, based on the typewriter legacy; neither Thai nor the other scripts using this model have conjunct forms." However, many other recently encoded scripts too have a different model where Indic_Syllabic_Category=Pure_Killer and Indic_Syllabic_Category= Invisible_Stacker are separated from Indic_Syllabic_Category=Virama. Such as Myanmar, Tulu-Tigalari, Masaram Gondi etc. In some these scripts characters with Indic_Syllabic_Category=Consonant_Preceding_Repha, Indic_Syllabic_Category=Consonant_Medial etc are also distinctly encoded instead of unifying with Virama. The board level major types of the encoding models in Abugidas/Indic scripts can be added in the same paragraph or elsewhere too in the core specification if there is a similar description of the different encoding model of Abugidas.
Date/Time: Tue April 28 10:30:26 PT 2026
ReportID: ID20260428103026
Name: Will Della-Libera
Report Type: Report Error in Publication/Data
Opt Subject: Proposal to Encode "Reverse Oblique" Character Property for Sarcasm/Irony
1. Introduction and Rationale
Modern written communication, particularly in digital contexts (text messaging, social media), suffers from
a "prosody gap." Approximately 50% of linguistic meaning is conveyed through non-verbal cues: cadence, tone,
emphasis, and pitch. The absence of these cues frequently leads to misunderstandings, especially regarding
sarcasm and irony, which rely on the difference between literal and intended meaning.
We hereby request the addition of a character property or variation selector that allows for "Reverse Italic"
(Left-Leaning Oblique) formatting. While punctuation marks have been proposed (e.g., the 19th-century 'irony
mark'), they are insufficient. They function as footnotes, clarifying meaning only after a statement is read
linearly. Integrated formatting is simultaneous; the reader perceives the tone and the symbol at the exact
same moment.
2. Visual Logic
Standard Italics lean forward, suggesting momentum or emphasis. A Left-Leaning Oblique functions as a visual
recoil. It indicates that the writer is "shying away" from the literal truth of the statement, creating an
intuitive visual "error" that matches the logical "error" of sarcastic speech.
3. Factors for Inclusion
A. Urgency and Usage: The widespread use of the /s tag on platforms like Reddit indicates a massive, unmet
need among users to clarify sarcastic intent.
B. Contextual Accuracy: Existing methods (caps, emojis) modify the meaning or emotional backdrop, but
"Reverse Oblique" specifically modifies the phonetics of the delivery.
C. Universal Application: This requirement is not limited to English; sarcastic inversion is a
cross-cultural feature.
The prosody gap leaves much of a person's meaning unsaid, and if one single change can make a substantial
difference in reducing that gap, it's a sarcasm/tongue-in-cheek adaptation.
Date/Time: Wed April 29 10:35:23 PT 2026
ReportID: ID20260429103523
Name: Philippe Verdy
Report Type: Report Error in Publication/Data
Opt Subject: Mende Kikakui M193 HON vs. Dalby’s NGGEE
In the Mende Kikakui script, the code charts (in English and French) include this note: 1E875 𞡵 MENDE KIKAKUI SYLLABLE M193 HON • Dalby’s M193 NGGEE has different shape and value However there's no evidence at all in the encoded syllables of what is the character for Dalby's M193 NGGEE, beside the notes say they have different shape and value. And it does not seem to be the same as these other "related" encoded characters: 1E873 𞡳 MENDE KIKAKUI SYLLABLE M087 HUN 1E87A 𞡺 MENDE KIKAKUI SYLLABLE M115 NGGEE 1E87B 𞡻 MENDE KIKAKUI SYLLABLE M146 NGGE IMHO, the Dalby’s M193 NGGEE character was forgotten during the encoding since Unicode 7.0.
Date/Time: Sun May 24 10:48:15 PT 2026
ReportID: ID20260524104815
Name: Simon Patrick
Report Type: Report Error in Publication/Data
Opt Subject: Correction for Roadmap (SMP)
In the Roadmap for the SMP, http://www.unicode.org/roadmaps/smp (as at 2026-05-08) the block “Musical Symbols Supplement” (1D250..1D28F) should be categorised as “Accepted for publication” (class acpt) rather than “Roadmapped” (rdmp) because it was accepted for Unicode 18.0 on 29 October 2025 (according to the pipeline) and appears in https://unicode.org/Public/draft/ucd/Blocks.txt.
Date/Time: Fri April 17 17:26:18 PT 2026
ReportID: ID20260417172618
Name: Jules Bertholet
Report Type: Report Error in Publication/Data
Opt Subject: Georgian_Extended has incorrect titlecase mappings
Letters in the Georgian script have two forms: the standard, lowercase-like "mkhedruli" form, and the
variant uppercase-like "mtavruli" form. The former are encoded in the Georgian block (U+10A0..U+10FF),
while the latter are in the Georgian Extended block (U+1C90..U+1CBF).
Unlike uppercase in other languages, however, mtavruli is only used in ALL CAPS contexts. It is not
Used In Titlecase or. To start sentences. More information can be found in the original proposal for
adding mtavruli to Unicode. Because of this behavior, that proposal very deliberately specified, and
Unicode adopted, that lowercase/mkhedruli Georgian letters should titlecase to themselves, and not
to the uppercase/mtavruli form. This ensures that applying the toTitlecase() transformation to a
mkhedruli string does not incorrectly give a mixed-case result:
Uppercasing converts mkhedruli to mtavruli: toUppercase("ქართული ენა") = "ᲥᲐᲠᲗᲣᲚᲘ ᲔᲜᲐ"
Titlecasing leaves mkhedruli unchanged: toTitlecase("ქართული ენა") = "ქართული ენა"
However, Unicode unfortunately neglected to also make mtavruli letters titlecase to mkhedruli.
Currently, these titlecase to themselves. When applying the titlecase tranformation to an entire
mtavruli string, this results in an incorrect mixed-case result:
Titlecasing converts mtavruli into mixed case, which is not valid in modern Georgian usage: toTitlecase
("ᲥᲐᲠᲗᲣᲚᲘ ᲔᲜᲐ") = "Ქართული Ენა"
This error should be corrected by changing the Titlecase_Mapping of all assigned codepoints in the
Georgian Extended block, setting it equal to the Lowercase_Mapping.
Date/Time: Tue April 28 20:27:43 PT 2026
ReportID: ID20260428202743
Name: Vikki McDonough
Report Type: Report Error in Publication/Data
Opt Subject: UAX #9 Unicode Bidirectional Algorithm
UAX #9 (latest version https://www.unicode.org/reports/tr9/tr9-51.html) states, in part: (section 1) "However, there are several scripts (such as Arabic or Hebrew) where the natural ordering of horizontal text in display is from right to left. If all of the text has a uniform horizontal direction, then the ordering of the display text is unambiguous. However, because these right-to-left scripts use digits that are written from left to right, the text is actually bidirectional: a mixture of right-to-left and left-to-right text." (section 3.2, table 4) Strong L Left-to-Right LRM, most alphabetic, syllabic, Han ideographs, non-European or non-Arabic digits, ... R Right-to-Left RLM, Hebrew alphabet, and related punctuation However, not all RTL scripts have LTR digits, and not all non-European-non-Arabic digits have strong left-to-right directionality. Several RTL scripts, both current (N'Ko, Mende Kikakui, Adlam) and historical (Old North and South Arabian, Imperial Aramaic, Manichaean, Parthian and Pahlavi, Palmyrene), have digits with strong right-to-left directionality, but the current wording of these sections of UAX #9 falsely implies that all RTL scripts use LTR digits, that all non-European-non-Arabic digits have strong left-to-right directionality, and that no digits have strong right-to-left directionality.
Date/Time: Thu June 04 19:22:01 PT 2026
ReportID: ID20260604192201
Name: Property Correction
Report Type: Report Error in Publication/Data
Opt Subject: Emoji_Presentation property for older characters
Hello, Please correct Emoji_Presentation property to No for all characters stabilized before Unicode 6.1, when the variation selectors became available, that were not initially encoded as emoji characters. Having some set to Yes causes text in spreadsheets that were composed before Unicode 6.1 to display with inappropriate color. As document authors could not have entered the variation selectors before they were standardized, it is critical to have characters that predate the variation selectors have Emoji_Presentation set to No. Thank you for your consideration.
Date/Time: Sat June 06 12:12:35 PT 2026
ReportID: ID20260606121235
Name: Diego Frias
Report Type: Report Error in Publication/Data
Opt Subject: Include U+11A7 in Normalization Tests
0 Proposal U+11A7 (HANGUL JUNGSEONG O-YAE) is a frequent source of bugs in implementations of canonical composition. I propose to include a test in the Unicode Normalization Forms Test Data File (https://www.unicode.org/Public/17.0.0/ucd/NormalizationTest.txt) that targets this character. 1 Rationale The Unicode core specification chapter 3 (https://unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/#G60469) recommends setting the following constants TBase = 0x11A7 TCount = 28 Almost all real-world implementations of canonical composition I have seen use these constants. The document also makes the following note: TBase is set to one less than the beginning of the range of trailing consonants, which starts at U+11A8. TCount is set to one more than the number of trailing consonants relevant to the decomposition algorithm: (11C216 - 11A816 + 1) + 1 However, many implementations miss this note and end up treating U+11A7 as if it were a trailing consonant. Here are implementations of canonical composition that have had this bug: Postgres (https://www.postgresql.org/message-id/B92ED640-7D4A-4505-B09F-3548F58CBB16%40dzfrias.dev) utf8proc (https://github.com/JuliaStrings/utf8proc/commit/0260ba56c81e5ef6f06c0804034a36284bcb8710) unicode-rs (https://github.com/unicode-rs/unicode-normalization/blob/576ae0b1407dd14854876c93f1a348df0c19dffe/src/normalize.rs#L218) 2 Details I propose the following line be added to the normalization test file, in Part0 (the Specific Cases section): AC00 11A7;AC00 11A7;1100 1161 11A7;AC00 11A7;1100 1161 11A7; # (가ᆧ; 가ᆧ; 가; 가ᆧ; 가; ) HANGUL SYLLABLE GA, HANGUL JUNGSEONG O-YAE This test should go after the other specific Hangul cases tests (after line 68 for version 17.0.0).
Date/Time: Thu June 11 19:30:21 PT 2026
ReportID: ID20260611193021
Name: Ned Holbrook
Report Type: Report Error in Publication/Data
Opt Subject: Unexpected Joining_Type for Samaritan
According to DerivedJoiningType.txt, Samaritan has characters with Joining_Type=Transparent but they do not appear in ArabicShaping.txt. How does this derivation occur?
(None at this time.)
Date/Time: Thu May 7 14:24:18 PT 2026
ReportID: ID20260507142418
Name: Kirk Miller
Report Type: Report Error in Publication/Data
Opt Subject: comments on L2/26-128
A few copy edits. > "These are only used by Japanese in horizontal text." It is not clear what this is saying. It sounds like it may be a usage restriction in Japanese that has been mis-stated as exclusive use by Japanese. If Japanese orthography is the only one to use 301D and 301F, then something clearer like: → "These are only used in Japanese, and then only in horizontal text." If instead it is only the horizontal restriction that applies to Japanese, but 301D and 301F are also used by other languages, then perhaps: → "In Japanese, these are only used in horizontal text." > "for quotation marks following Latin width" It is not clear whether this means these quotation marks are set as Latin-width glyphs, or if they are used in the context of Latin-script text (and presumably precede as well as follow). So maybe: → "for quotation marks, set to Latin width" or → "for quotation marks enclosing Latin-width text" Minor c.e.: > "and follows Latin typographic conventions." → "and follow Latin typographic conventions." > "The Sibe script consistently use the curly style quotation marks" → "The Sibe script consistently uses the curly-style quotation marks"
Date/Time: Tue May 12 13:45:10 PT 2026
ReportID: ID20260512134510
Name: Wyatt Carpenter
Report Type: Report Error in Publication/Data
Opt Subject: current Unicode standard recommends middle dot
My impression is that the word separator middle dot, being a disunified sense of middle dot, should always be preferred to a middle dot for use as a word separator, with ordinary middle dot being supported only as a legacy compatibility allowance (albeit one that will continue forever into the future). However, if you search through the Unicode core spec for middle dot, you can find many language specific sections recommending you use the middle dot. I think these should probably all be changed to say that you should use the wsmd and also that most digital text found in the wild uses the ordinary md. Thanks for your time!
Date/Time: Tue May 12 14:02:37 PT 2026
ReportID: ID20260512140237
Name: Wyatt Carpenter
Report Type: Report Error in Publication/Data
Opt Subject: removal of tag characters from the standard
Starting in v16 or something like that, the section on tag characters in the unicode standard has omitted the full description of the deprecated use of tag characters, instead linking to it. I think this is probably the wrong choice. This probably isn't covered by any formal "stability policy" per se, but the core spec should probably give you all the information you need, less the technical reports I guess, to work with text in any version of Unicode (past, say, 2, I guess, for complicated reasons), even the depricated ones. I recently purchased a physical copy of the Unicode standard from before this removal was made, and I would have been very disappointed if I had come to a link to this old version while reading. I cannot click the book. But I freely admit my biases are somewhat antiquarian. Thanks for your consideration!
Date/Time: Sat Jun 06 09:36:29 PT 2026
ReportID: ID20260606093629
Name: Tim Pederick
Report Type: Report Error in Publication/Data
Opt Subject: Error in Unicode spec §23.8.1
In the current version (17.0.0) of the Unicode core specification, the following text appears in section 23.8.1 “Byte Order Mark (BOM): U+FEFF”:
In the UTF-16 encoding form, a BOM at the very beginning of a file or stream explicitly signals the byte order. When an interpreting process
finds U+FFEF as the first code unit, it signals that the text is in UTF-16 in the expected byte order.
“U+FFEF” should read “U+FEFF” as in the section title. (U+FFEF is an unassigned code point in Halfwidth and Fullwidth Forms, unrelated to the BOM.)
Date/Time: Sat June 27 13:49:29 PT 2026
ReportID: ID20260627134929
Name: Ismael RH
Report Type: Report Error in Publication/Data
Opt Subject: EPA and the Delta Chart for Latin Extended-G
I would like to request the inclusion, in the EPA section of the upcoming Unicode 18.0 chart for Latin Extended-G, of the following explanatory text, placed prior to the characters: Individual versions of the EPA often featured different casing conventions for certain letters. Official Unicode case pairings follow those of the 1856 and 1868 versions. Thank you in advance for taking the time to read my suggestion.
Date/Time: Sun May 17 10:06:24 PT 2026
ReportID: ID20260517100624
Name: Huang Junliang
Report Type: Report Error in Publication/Data
Opt Subject: Seal code charts
Huang Junliang has reviewed the code charts for Seal once again; here is his report: ``` Found 19 issue(s) in seal.csv: - Line 206 3D0CC: character is empty - Line 628 3D272: character is empty - Line 647 3D285: character is empty - Line 892 3D37A: character is empty - Line 2434 3D980: character is empty - Line 2936 3DB76: character is empty - Line 4451 3E161: character is empty - Line 5281 3E49F: radical out of order — previous 267, got 264 - Line 6059 3E7A9: radical out of order — previous 523, got 296 - Line 6452 3E932: radical out of order — previous 322, got 321 - Line 6737 3EA4F: character is empty - Line 6757 3EA63: character is empty - Line 7070 3EB9C: character is empty - Line 7751 3EE45: character is empty - Line 8165 3EFE3: character is empty - Line 8956 3F2FA: character is empty - Line 9049 3F357: character is empty - Line 9092 3F382: character is empty - Line 9594 3F578: character is empty ``` Please check.
Date/Time: Fri May 29 17:34:57 PT 2026
ReportID: ID20260529173457
Name: Eiso Chan
Report Type: Report Error in Publication/Data
Opt Subject: Feedback on PRI #544
I help TCA provide feedback on the Small Seal code charts below. TCA agrees with Kushim’s suggestions for two characters. In fact, the issue with U+3EC25 was already included in the 22 adjustments (2 radicals and 18 Modern CJK) that Selena submitted on April 24 for ISO/IEC 10646 CD 4. After checking the newly released Unicode 18.0 Beta version, They noticed that these 22 items still need to be updated as below. Therefore, they provided the following list here, along with the new Modern CJK issue for U+3FB84 raised by Kushim. Here is the complete list for your review: (Note: Values after the arrow (→) are the suggested corrections.) # Raical(SealSources.txt) U+3DDF7 kSEAL_Rad 157.3DDF1→158.3DDF7 U+3DDF8 kSEAL_Rad 158.3DDF8→158.3DDF7 U+3DDF9 kSEAL_Rad 158.3DDF8→158.3DDF7 U+3DE44 kSEAL_Rad 168.3DE31→169.3DE44 U+3DE45 kSEAL_Rad 169.3DE45→169.3DE44 U+3DE46 kSEAL_Rad 169.3DE45→169.3DE44 # Modern CJK U+3E894 kSEAL_MCJK 824E 艎→26A84 𦪄 U+3E9FB kSEAL_MCJK 9B1F 鬟→29BF4 𩯴 U+3EA95 kSEAL_MCJK 5D99 嶙→21F64 𡽤 U+3EB4D kSEAL_MCJK 787E 硾→2558C 𥖌 U+3EC24 kSEAL_MCJK 298B2 𩢲 → 298EC 𩣬 U+3EC28 kSEAL_MCJK 9A02 騂→2994D 𩥍 U+3EF54 kSEAL_MCJK 61C7 懇→22846 𢡆 U+3F153 kSEAL_MCJK 703C 瀼→2416D 𤅭 U+3F160 kSEAL_MCJK 6F35 漵→6F4A 潊 U+3F161 kSEAL_MCJK 6E2F 港→23FD1 𣿑 U+3F163 kSEAL_MCJK 6FD4 濔→24164 𤅤 U+3F167 kSEAL_MCJK 6E98 溘→23E46 𣹆 U+3F2DB kSEAL_MCJK 95E4 闤→28DE4 𨷤 U+3F80A kSEAL_MCJK 867B 虻→8771 蝱 U+3F8FD kSEAL_MCJK 587E 塾→2150A 𡔊 U+3FA4E kSEAL_MCJK 6235 戵→947A 鑺 U+3FAFB kSEAL_MCJK 8F54 轔→283CF 𨏏 U+3EC25 kSEAL_MCJK 298CA 𩣊→2992D 𩤭 U+3FB84 kSEAL_MCJK 25747 𥝇→25745 𥝅 (rasied by Kushim)
Date/Time: Mon June 08 17:41:12 PT 2026
ReportID: ID20260608174112
Name: Harriet Riddle
Report Type: Report Error in Publication/Data
Opt Subject: PRI 544 [CHARTS]
Some NamesList.txt annotation addition suggestions for Charts WG (lines starting with +):
---
223F SINE WAVE
= alternating current
+ x (ac current - 23E6)
2240 WREATH PRODUCT
+ x (vertical tilde - 2E2F)
[…]
2264 LESS-THAN OR EQUAL TO
x (less-than sign - 003C)
+ x (angle with underbar - 29A4)
2265 GREATER-THAN OR EQUAL TO
x (greater-than sign - 003E)
+ x (reversed angle with underbar - 29A5)
[…]
227C PRECEDES OR EQUAL TO
+ x (precedes above single-line equals sign - 2AAF)
+ x (precedes above equals sign - 2AB3)
227D SUCCEEDS OR EQUAL TO
+ x (succeeds above single-line equals sign - 2AB0)
+ x (succeeds above equals sign - 2AB4)
227E PRECEDES OR EQUIVALENT TO
+ x (precedes above almost equal to - 2AB7)
227F SUCCEEDS OR EQUIVALENT TO
+ x (succeeds above almost equal to - 2AB8)
[…]
22DC EQUAL TO OR LESS-THAN
+ x (slanted equal to or less-than - 2A95)
22DD EQUAL TO OR GREATER-THAN
+ x (slanted equal to or greater-than - 2A96)
[…]
237C RIGHT ANGLE WITH DOWNWARDS ZIGZAG ARROW
+ = azimuth
[…]
2393 DIRECT CURRENT SYMBOL FORM TWO
+ x (straightness - 23E4)
[…]
23E4 STRAIGHTNESS
+ = direct current symbol form one
+ x (direct current symbol form two - 2393)
23E5 FLATNESS
23E6 AC CURRENT
+ x (sine wave - 223F)
[…]
29A4 ANGLE WITH UNDERBAR
+ x (less-than or equal to - 2264)
29A5 REVERSED ANGLE WITH UNDERBAR
+ x (greater-than or equal to - 2265)
[…]
2AB7 PRECEDES ABOVE ALMOST EQUAL TO
+ x (precedes or equivalent to - 227E)
2AB8 SUCCEEDS ABOVE ALMOST EQUAL TO
+ x (succeeds or equivalent to - 227F)
[…]
2E2F VERTICAL TILDE
* used for Cyrillic yerik
x (combining vertical tilde - 033E)
+ x (wreath product - 2240)
x (cyrillic payerok - A67F)
Date/Time: Sun July 05 07:27:52 PT 2026
ReportID: ID20260608174112
Name: Wyatt Carpenter
Report Type: Report Error in Publication/Data
Opt Subject: Formal alias for click consonants
I am no expert in this, but I hear the names Unicode uses for certain click consonants is obsolete now that the IPA has standardized its vocabulary. For instance the "retroflex click" character ⟨ǃ⟩ is apparently known as an alveolar click by everyone now, and the "alveolar click" ⟨ǂ⟩ is now known as the palatal click. It may be worth consulting with the IPA about this and creating formal aliases to correct the names. It wouldn't be so bad to have the current names, except that they actively indicate the wrong one. This also presumably affects 1DF0A LATIN LETTER RETROFLEX CLICK WITH RETROFLEX HOOK, A71D ꜝ modifier letter raised exclamation mark, and 107B9 modifier letter retroflex click with retroflex hook Unicode Technical Note #27: "Known Anomalies in Unicode Character Names" should also be updated, if my info is true.
(None at this time.)