Yes, you’re right. When step size information is present in the track file header, this is used to calculate the length of each streamline more quickly; but if the streamlines have undergone a non-linear transformation, such an approach is no longer accurate.
(The reason the lengths are not precisely equivalent is because the length of the first and last steps of the streamline are not guaranteed to be equal to the step size, so these two are always calculated explicitly, and those lengths will vary slightly between tracks with and without the normalisation applied)
If you’re feeling adventurous, you could use a hex editor to modify the track file header information: Set the values for both
output_step_size to 0, making sure that the length of the header remains unchanged and the delimiters between key-value pairs remain intact. If performed correctly, that should cause
tckstats to explicitly calculate the length of each streamline the slow way, i.e. summing the distance between each successive point along the entire length of each streamline.
I suspect it will be necessary in the future for
tcknormalise to erase the