I would treat the original camera files as the telemetry masters and avoid destructive preprocessing. Many generic join/transcode tools care only about the audio/video streams and may discard metadata tracks that a telemetry tool expects.

My workflow is: archive the original chapters, verify that telemetry exists in them, then import those originals into the telemetry/editor workflow. Only create the presentation/export file after the data has been extracted or linked.

That also helps with gaps. On a two-hour ride I once had one short chapter with bad GPS reception. If I had flattened everything first, it would have been harder to identify which part of the recording caused the odd speed spike.

If the goal is visible gauges rather than preserving proprietary GoPro telemetry inside a new master file, VSDC can simplify this. Current versions can detect GPS/telemetry embedded in supported action-camera footage and place the extracted data in project resources. You can then synchronize it with the video and build route/speed/altitude overlays.

I would still import the original GoPro chapters rather than an intermediate “joined” file. That keeps the camera metadata available at the point where the editor reads it. After that, edit the chapters as one sequence and render the finished video with the overlays burned in.

That distinction was what I was missing: preserving the original telemetry stream inside a newly joined MP4 is a different problem from extracting the telemetry and using it for overlays.

For YouTube I only need the second option, so I will keep the originals, extract from them, edit the chapters continuously and render the gauges into the final video.

Exactly. And keep the untouched camera card copy until the project is delivered. GPS/gyro metadata is one of those things people discover they need two weeks later, after the convenient transcoded files have already replaced the originals.