Thank you very much for your insightful and quick response!
Tools will look at the fastq headers to ensure that paired-end reads are next to each other when files are sorted (e.g. BAM) so
samtools,featureCountsetc. Tools that can mark read duplicates (optical/PCR) will use those coordinates e.g.clumpify.shfrom BBMap suite.
I guess, I should just run a few tests with those tools...thanks for pointing out which ones might be affected. But don't they rather rely on the accordance of the lane:tile:x_pos:y_pos part of the read ID to verify pairs? In this case, it might be acceptable if the read number of the mate is 3:N:0 instead of 2:N:0?
That is the old style of Illumina identifiers and not actively used now.
I was just aware that there are different notations (sometimes even using an underscore), but didn't know which one is the current standard. Thanks!
It is more a matter of software being aware of the reads containing UMI.
We discussed, if we should deliver the files with already embedded UMIs, but eventually felt that delivering three FastQ files would be more flexible. Subsequently, it would still be possible to embed the UMIs as required for the tool of choice, whereas users not interested in using UMIs throughout the analysis could just ignore the third file.