After some deeper FIT analysis I believe I have found a bug in the average stride-length that is injected as native FIT data (not developer) from the HRM-RUN/TRI/PRO as avg_step_length into type 19 laps
This bug also exists in type 20 records but it is less obvious because of how short of a time period records are as just a second or two
The overage session type 18 (full activity) step-length is far more accurate on average. So it's not likely a hardware failure but rather math / counters.
(since avg_step_length doesn't exist on a bare fenix5 and I had those functional fields before stryd I have to assume it is from HRM accelerometer)
I can provide exact/more data if required but it is simple math to see the lap time vs lap cadence does not properly calculate into stride-length, it is too short.
What appears to be happening is the calculation is using the whole session based average stride-length and not zero-ing out at the start of each lap.
But cadence measurement for session, laps, records, all do seem to match from the watch, HRM and even vs stryd so that's accurate (easy to count impacts in hardware).
I doubt this calculation is done in the HRM strap but rather on the watch itself. Which means the firmware would have to be fixed on each model.
This is on a Fenix5 with HRM-TRI, I am assuming the bug exists in other models but may be fixed on Fenix6 as I have no way of testing that.
I also have a Forerunner 620 with HRM-RUN v1 strap but it does not appear to calculate/inject avg_step_length so this must be a newer strap feature.
tl;dr the HRM step-length calculation does not reset for each lap and uses the overall session step-length for the FIT recording, this is technically wrong behavior and therefore a software bug