[nitpick] Unnecessary blank line added. This extra whitespace doesn't serve any purpose and should be removed.

The variable si is declared but never used. It can be removed since only ParseCombiningCharacters() is needed here.

The offset parameter semantics have changed in an incompatible way. Previously, offset was a character index in the string. Now it's being treated as an index into the textElementIndexes array (line 60: if (i < offset) continue). This is a breaking change that could cause incorrect behavior when callers pass a character offset expecting the old behavior.

Consider either:

1. Maintaining backward compatibility by converting the character offset to a text element index, or
2. Documenting this breaking change if intentional

Performance concern: Using StringInfo.ParseCombiningCharacters() and Substring() for every call to Length() can be significantly slower than the previous character-by-character iteration, especially for long strings. ParseCombiningCharacters() allocates an array and performs multiple string scans.

For most strings (which don't contain complex grapheme clusters), this is unnecessary overhead. Consider adding a fast path that only uses the grapheme cluster approach when necessary:

// Fast path: check if string likely contains complex graphemes
bool needsGraphemeProcessing = str.Any(c => char.IsSurrogate(c) || c >= 0x0300);
if (!needsGraphemeProcessing) {
    // Use simpler character-by-character processing
} else {
    // Use grapheme cluster processing
}

Missing several important emoji ranges that should be treated as wide (2 cells):

• 0x1F000-0x1F02F (Mahjong Tiles, Domino Tiles)
• 0x1F0A0-0x1F0FF (Playing Cards)
• 0x1F100-0x1F5FF (Enclosed characters)
• 0x1FA00-0x1FA6F (Chess Symbols, etc.)
• 0x2B50-0x2B55 (Stars and symbols)
• 0x2300-0x23FF (Miscellaneous Technical)

These ranges are covered in CodePointLengthInBufferCells() but should also be included here for consistency.

The GraphemeLengthInBufferCells() method doesn't handle wide CJK characters properly. It only checks for emoji ranges but ignores the existing CJK width logic in CharLengthInBufferCells(). A grapheme containing CJK characters should still be calculated as 2 cells wide, but this implementation defaults to returning 1 (line 95).

Consider falling back to CharLengthInBufferCells() for BMP characters that aren't emojis, similar to how CodePointLengthInBufferCells() does on lines 182-184.

Inconsistent indentation: This method has excessive indentation (appears to be indented as if it's inside another block). It should align with other methods in the class.

The GraphemeLengthInBufferCells() method only checks the first code point of a grapheme cluster (line 81), but grapheme clusters can contain multiple code points (e.g., base character + combining marks, or emoji with skin tone modifiers). This will give incorrect results for complex graphemes.

For example, "👨‍👩‍👧" (family emoji) is a single grapheme but consists of multiple code points joined with zero-width joiners. The current implementation would only check the first code point.

Consider using a more comprehensive approach that accounts for the full grapheme structure, or leveraging existing Unicode width calculation libraries.

Overlapping ranges detected: The range 0x1F300-0x1F9FF on line 163 already includes 0x1F900-0x1F9FF (line 168). The duplicate check on line 168 is redundant and should be removed.

Overlapping ranges detected: The range 0x1F100-0x1F64F on line 166 already includes 0x1F170-0x1F251 (line 173). The duplicate check on line 173 is redundant and should be removed.

Condition always evaluates to 'false'.

[nitpick] Potential issue with backward traversal: When going backward and encountering a low surrogate at line 251, the code skips it (line 254) but then at line 299, k is decremented again. This could cause the algorithm to skip over the high surrogate entirely without processing it.

Example: If k is at a low surrogate and startFromHead=false:

1. Line 251 detects low surrogate
2. Line 254: k = k - 1 (now at high surrogate)
3. continue jumps back to loop start
4. Line 239 check passes
5. Line 257 detects high surrogate and processes it correctly
6. Line 299: k = k - 1 (moves backward)

Actually, on second review, this appears correct since the continue statement jumps back to the start of the loop. However, the logic is confusing and error-prone.