Potential incomparable UMI's because of allowed extra characters

[veldsla]

When the UMI is parsed from the Illumina (compatible) read name the UMI is allowed to contain either + or _ characters. These are not removed from the sequence and when the layout of all UMI sequences in the BAM file is identical this is not an issue.

However when the UMI layout in the readnames varies across records this may leaf to comparing what are essentially incomparable UMI's.
We probably want to error-out of the program if this happens, although it seems a bit like an edge case.

[werner291]

Hi! I was looking at this issue and started writing a failing test to understand the behavior. I should be upfront: I'm a software engineer, not a bioinformatician — I can see the structural problem (UMIs with different layouts being compared byte-by-byte) but I don't have the domain knowledge to judge what the correct normalization would be. So I'd rather ask than guess wrong.

A few questions:

1. Can separator position vary within a file? e.g. ACGT+AC vs AC+GTAC?
2. Can separator character vary? e.g. + and _ mixed in the same file?
3. Is it always some-have-separators vs some-don't, or can it get weirder?
4. Is it safe to just strip separators and compare bases only? If so, the cleanest fix would be a Umi newtype that normalizes on construction — separator layout mismatches become structurally impossible because Dist only ever sees bases. No error path needed because the bad state can't exist.

If stripping isn't safe, some fallback options from least to most invasive:

• Check that all UMIs have the same length, panic on mismatch
• Record the first UMI's separator pattern, return an error if a later one differs
• Propagate that error properly through Dist (currently returns usize with no error path)

Happy to implement whichever fits.