1) Devanagari–Gujarati cross-script confusability:

Many Devanagari and Gujarati characters share similar shapes; the primary structural difference is typically the presence or absence of the Shiro-rekha. Because Devanagari text is often rendered without a headline in certain environments, an end user may misinterpret Gujarati script as Devanagari rendered without a Shiro-rekha. Thus, Gujarati strings may visually resemble “headless” Devanagari forms, even though Gujarati is generally more cursive.

Given this, careful cross-script comparison between Devanagari and Gujarati variants is essential. From an end-user perception standpoint, a TLD could easily be mistaken for Devanagari, making this a meaningful area for attention.

2) Need for deeper syllable-level analysis for cross-script variants

Given the syllabic nature of Indian scripts, cross-script variants should ideally be investigated at the syllable level, not only at the individual code-point level. The current SSE methodology addresses this to a reasonable extent, but additional refinement may be beneficial. Certain sequences—particularly involving conjuncts, combining marks, and multi-sign clusters—appear to warrant further review. The complexity of these scripts suggests that the variant lists may need periodic extension or update as more real-world cases emerge.

Ignore if taken care of :

ह -> ह्

ॸ्क :  U+0978 U+094D U+0915 -> एक : U+090F U+0915

ॸय :  U+0978 U+092F -> ॸ्य :  U+0978 U+094D U+092F , ਮ੍ਪ :  U+0A2E U+0A4D U+0A2A, ਸ੍ਪ : U+0A38 U+0A4D U+0A2A

ब्र  = ब + ् + र = U+092C U+094D U+0930 

ब्ग = ब + ् + ग = U+092C U+094D U+0917 , ब्न = ब + ् + न = U+092C U+094D U+0928 

व्न -U+0935 U+094D U+0928 व्ग - U+0935 U+094D U+0917

व्र ह्र ह्ग ह्न ग्र  

1) Potentially incorrect type-1 variant mapping for U+0901 (DEVANAGARI SIGN CANDRABINDU) :

In the Devanagari SSE file (sse-devanagari-script-11oct25-en.xml), the entry for U+0901 DEVANAGARI SIGN CANDRABINDU (ँ) includes a type-1 variant mapping to the sequence U+0945 U+0942 (ॅू) under the follows-C-or-CN context. Visually, these forms are not strongly similar. U+0901 is a single nasalization mark placed above the base. U+0945 U+0942 is a combination of an above-vowel sign and a below-vowel sign, with no nasal dot and with substantially different visual structure. They are neither canonically related nor typical fallback representations. This mapping may therefore warrant re-evaluation.

I acknowledge that it is not feasible to enumerate every possible variant, and that manual expert review remains the most effective way to reach final decisions. With that understanding, I would like to offer the following observations / clarifications:

- Scope limitations of SSE/MSR versus broader user-perceived confusability

The SSE and MSR frameworks are deliberately limited to the Root Zone variant-management context, and therefore do not cover the full spectrum of visually confusable Unicode characters encountered in everyday user experience. In particular, case-folded ASCII homoglyphs and Unicode TR39 confusable mappings (e.g., MOCKBa (U+004D U+004F U+0043 U+004B U+0042 U+0061) vs. москва (U+043C U+043E U+0441 U+043A U+0432 U+0430)) fall outside the MSR repertoire and thus do not appear in SSE-generated similarity sets. This is consistent with ICANN’s LGR architecture and its intentionally narrow policy scope.

However, to support evaluators—especially within the String Similarity Review Panel—it may be beneficial for tools to offer an optional extended mode, incorporating TR39 confusable, ASCII homoglyphs, case-fold and uppercase mappings, alongside the strict SSE-defined sets. Such a dual-mode evaluation (strict LGR/SSE vs. extended confusable view) would respect current Root Zone policies while enabling reviewers to explore a more complete, perception-based similarity landscape where appropriate. Although Rule A requires comparing all elements to ASCII characters in uppercase and lowercase form (a–z, A–Z), in practice the SSE-derived variant sets remain restricted to characters included in the MSR repertoire.