Unicode text can contain different scalar sequences that are canonically related and often render alike. The precomposed letter é is one value, U+00E9. A decomposed spelling uses U+0065 followed by U+0301. Treating them as the same for search or comparison can be useful, but changing one into the other is a separate normalization operation and would destroy exact input evidence.
The two spellings produce different evidence
In UTF-8, U+00E9 becomes C3 A9. The sequence U+0065 U+0301 becomes 65 CC 81. Their scalar counts are one and two, their UTF-16 unit counts are one and two, and their byte counts are two and three. UnicodeLens displays those facts without deciding whether a font will render the results identically. The composition preset places both spellings beside a separator so the row order remains easy to verify.
Inspection and normalization are separate jobs
An inspector should preserve the value it claims to inspect. UnicodeLens does not apply NFC, NFD, NFKC or NFKD, does not fold case and does not remove variation selectors or joiners. A future normalization product would need explicit forms, before-and-after evidence, compatibility-loss warnings and executable conformance data. Keeping that operation outside this tool makes copied U+ and byte sequences faithful to the textarea rather than to an undocumented repair step.
Choose comparison rules in the consuming system
Databases, programming languages, file systems and search systems do not all normalize or compare text the same way. Even canonical equivalence does not answer locale collation, grapheme segmentation, spoofing or identifier policy. Use UnicodeLens to capture the exact sequence, then apply a documented comparison policy where the data is consumed. Do not infer that two visually similar results are identical, interchangeable or safe from the rendered glyph alone.