Yes am happy to close the bug report. Thanks for all your work.

Problem with "COURSE_19341403.gpx"
error on line 266 because dcol is 0. It does not get assigned correctly.

This if statement doesn't work for case of having time but not elevation.
I think the has_ele should be removed from first if statement.

            if (it && has_ele)
              if (! has_ele)
                ## No "ele" subnodes
                ptrnt = ptrnt1C;
                dcol = 3;
                ncols = 3;
              elseif (has_ele < it)
                ## ele nodes come before time nodes
                ptrnt = ptrnt1A;
                dcol = 4;
                ncols = 4;
              else
                ## time nodes come before ele nodes
                ptrnt = ptrnt1B;
                dcol = 3;
                ncols = 4;
              endif
            elseif (has_ele)
              ptrnt = ptrnt2;
              ncols = 3;
            else
              ## Just Lat and Lon nodes
              ptrnt = ptrnt3;
              ncols = 2;
            endif


After changing this the file was read correctly

Right, so dropping a regexprep makes for a little better performance. Good to know, thanks.

The warning seems to be issued because the 'trkseg' nodes lack elevation subnodes; so there's another regexp format string required plus some fixes in the subsequent array processing logic. Tonight I'll have a look at that.
My next fear is that there may be .gpx files Out There that lack both time and elevation subnodes. Just to be sure I'll try to tackle that as well.

Have tested successfully with about 100 files and found a couple with an issue.
Here is the Warning.

warning: your pattern caused PCRE to hit its MATCH_LIMIT; trying harder now, but this will be slow
warning: called from
    gpxread at line 219 column 19

I will attach an example file.

Also looking at your fix I think the second regexprep is not needed as datenum will match with 1, 2 or 3 decimal places filled.

>> datenum('2020-08-03T18:05:29.001Z','yyyy-mm-ddTHH:MM:SS.FFFZ')

ans =  738006.75381

>> datenum('2020-08-03T18:05:29.01Z','yyyy-mm-ddTHH:MM:SS.FFFZ')

ans =  738006.75381

>> datenum('2020-08-03T18:05:29.1Z','yyyy-mm-ddTHH:MM:SS.FFFZ')

ans =  738006.75381

>> datenum('2020-08-03T18:05:29.Z','yyyy-mm-ddTHH:MM:SS.FFFZ')

ans =  738006.75381

>> datenum('2020-08-03T18:05:29Z','yyyy-mm-ddTHH:MM:SS.FFFZ')

error: ds(0): subscripts must be either integers 1 to (2^63)-1 or logicals
error: called from
    datevec>__date_str2vec__ at line 268 column 12
    datevec at line 144 column 54
    datenum at line 113 column 46

Yeah, mixed time format fields are going to be a big PITA.
That is because Octave's datenum function (like Matlab's) isn't smart enough to parse a date string vector with varying formats.
I have an idea on how to tackle this but I'm afraid it's going to be a kludge at first; an IMO satisfactory solution may need a little bit more time. Hopefully you'll stay with this bug report until a/the final fix is available.
Good that you uploaded a test file, thanks.

BTW I have plans to make a new mapping release soon, hopefully before Octave-6.1.0 is released (I guess within 4-6 weeks). As to gpxread.m, the current fixed version as it stands now is the bottom line so to say. Improved versions might come after a new release.

I've pushed a fix here:
http://hg.code.sf.net/p/octave/mapping/rev/cd4ece3dd87e
and attached a new gpxread.m here.
Please try it and report if it fixes your problem.

[Slightly OT]
I also had a look at uncovering Time values from Waypoint nodes (these are currently not read). ATM that isn't possible w/o incurring a severe performance penalty.
In case someone wants that functionality please open a new bug report / feature request for it.

(file #49596)

Could you please upload an example gpx file that shows the issue?
The ones I have (and that I used for development) are all accepted by gpxread.m.
If confirmed kmlread and kmzread might also be affected.

Note that I'll have very limited time for Octave the next weeks so don't expect further progress until early August. (Unless someone beats me to it.)