Hi and thanks for your feedback!

I guess you're right about g_queue_free_full vs. g_queue_free. I must admit, that I missed that one as I was working with apparently outdated documentation not mentioning the existence of g_queue_free_full. But of course we should free the track point objects as well. I changed that in the attached patch, please check it.
Or should we probably even only free them and shrink the list rather than completely free the list and reallocate memory for list? Would that be any faster or had other advantages? I just chose it as an easy and quick way...

About the possible races and stuff... Well, to be honest I didn't think about that, good point of yours!
Now, as you mentioned it, I realised that the parts accessing the trip meter variables apparently aren't synchronised but maybe really should be!? Without the access on the list track point this may have only produced weird displays. (What happens if, in the middle of resetting the four trip meter variables in on_button8_clicked(), say after setting the first two of them to zero, cb_gps_timer() changes them? If that scenario was possible, I assume, the first two have non-zero values the last two have zero values, thus overall an inconsistent state.) But it can then, involving the track point list, in deed possibly even lead to access on freed memory or things like that, I guess. At least some thoughts on synchronising that cannot hurt, can it?
As far as I understand it, apart from any initialisation code, we have five functions to worry about conflicts accessing the trip meter variables (as they are trip_counter_on, trip_maxspeed, trip_time, trip_starttime, trip_distance and trackpoint_list):
(1) on_button8_clicked() in callbacks.c,
(2) on_button15_clicked() in callbacks.c,
(3) cb_gps_timer() in gps_fucntions.c,
(4) set_label() in gps_functions.c
and (5) paint_track() in tracks.c.
I thought about introducing a mutex to have them synchronised. However, that might need some thoughts on possible deadlocks. As far as I understand, that will at least require to reorder the code in cb_gps_timer() to get the critical section(s) together and eliminate some unhandy interleaving -- (a) do the calculations, then (b) update the variables and (c) do all the repainting stuff (like possibly calling set_mapcenter(), which will call paint_track(), calling set_label(), ...); lock the mutex before (b) and unlock it afterwards as parts of (c) might also need to lock it for themselves (e.g. paint_track(), which could also be called from elsewhere hence needs its own lock and gets called in cb_gps_timer() via calling set_mapcenter()). Could that be a feasible way in your opinion? I could try to get my hands on that then...

I use the NULLs in the list of track points as a stop marker. Hence, whenever there's a NULL, everything left of it belongs to one section of the track, everything right of it to another section. As there we're no sectioning of the track in the code before all the NULL stuff is an extension to handle them now (plus one sort of fix also affecting the handling with only one section as it is now in the release). I inserted some comments in the attached patch hopefully giving you the ideas behind it.
Inserting NULLs in the list as marker was a quick idea not leading to too much changes in the code. However, probably using a list of lists would be cleaner and might be more handy for future features, like e.g. deleting only a few sections rather than resetting the whole track. What do you think?