Based on our review of the String Similarity Evaluation Data for the New gTLD Program: Next Round and its described methodology, we are not in a position to reliably identify specific additional code-point pairs that are clearly missing from Categories 1–3. The dataset appears to be the result of structured, script-expert work over the full RZ-LGR-6 repertoire, including cross-script comparisons and a transitivity pass. From the perspective of NCSG and NPOC members, our main concern is therefore not that obvious pairs are missing, but that any future omissions discovered in practice could have a direct impact on: (1)End-users, if confusingly similar strings are not captured; and (2) Smaller or noncommercial applicants, if the correction process is unclear or slow, creating uncertainty about potential contention. We therefore recommend that ICANN clearly document a continuous improvement mechanism for the SSE Data, allowing script communities and affected stakeholders to submit evidence-based proposals for new confusable pairs, with transparent expert review and timely updates. This will help ensure that any missing visually similar pairs can be added in a predictable and accountable manner as operational experience accumulates.     

Based on the general description provided in the String Similarity Evaluation background materials, a proper determination would require a detailed examination of the XML/HTML datasets and script-specific rules in the RZ-LGR-6. However, if during the review any pairs are found to be incorrectly classified—for example, pairs that are not visually confusable in normal usage or lack linguistic or contextual overlap—they should be reassigned to category 4 or 5. In such cases, the recommended format for reporting would be: code point 1, code point 2, updated category (e.g., m, rn, 2).     

At this stage, we do not propose specific changes to the similarity category of individual code-point pairs. The current assignments are based on RZ-LGR variant definitions, detailed script-expert review, and cross-script consistency checks. From an NCSG perspective, our priority is that ICANN and the relevant script communities periodically re-evaluate borderline cases using real end-user testing (including users from under-resourced scripts and regions), and that any future changes to Categories 1–3 be clearly documented with rationale and examples so that applicants and registrants can understand how and why similarity categories evolve over time.

  If a mapping is not all category 3 or less it means that there's at least one code point which can differentiate the two strings. The mapping category information will be presented to the SSE Panel and they may decide that these are not similar. 

The extent and nature of permissible modifications and their respective deadlines have not been clearly outlined in Section 6 ("Applicant Support Program Application Process") of the ASP Handbook. It is essential to clarify what changes are allowed and the process for implementing them, including specific timelines. This clarity is vital for maintaining transparency, fairness, and consistency throughout the application process.

As the Chinese, Japanese and Korean script would evolve from time to time, the chance on the visual similarity on those scripts would remains open, especially Japanese and Chinese which both use Kanji in their respective language, where similar/almost similar character might have different meaning. To avoid end user confusion, we suggest to have collaboration with the script communities and have periodically update to capture the possibilities of change within script.