Hmmm. This all looks very hacked together.
Unfortunately GC baked metadata into their data which has been used quite inappropriately across the developer communities and is now somewhat difficult to make amendments to.
i.e. The "GC" code indicates to a lot of developers that this is a Geocache from Groundspeak, vs. say a SH which is a shutterspot or a GA which is Geocaching Australia or OX which is OpenCaching or OU which is OpenCaching US or OK which is OpenCaching UK, etc.
Having "something else" which may not be a consistent value AL or LC is a challenge. Not impossible, but needs careful handing to make sure none of the other special rules get out of alignment.
<url>
https://labs.geocaching.com/goto/WPWA</url> That doesn't seem unique enough. No idea how this is generated or obtained.
<type>Geocache|Lab Cache</type> isn't going to show up a map icon on a GPS unit. We don't use that though, we use the type from the the groundspeak extension.
<groundspeak:type>Lab Cache</groundspeak:type> is OK and we could handle that by adding it into our GPX importers along with icons and whatnot. As the GPX xsd does not enumerate types any other developer who creates a lab cache GPX could use a different name. If this was all coming from GC it would be consistent, but from other sources, could be lab cache or LAB cache or Laboratory Cache or any combination of data.
<groundspeak:cache id="-1" is not a problem as we don't use it, but that's a shitty hack. The ID is supposed to IDENTIFY something. It's not "just a number".
<groundspeak:country />
<groundspeak:state />
Hmmm. Not nice. If we don't get a country and state we recognise then we'll use a Geocoding service to get it, so it's not an issue, just a bit of a shitty hack not to provide it.
From the xsd:
<xs:element name="country" msdata:Prefix="groundspeak" type="xs:string" minOccurs="0" msdata:Ordinal="7"/>
<xs:element name="state" msdata:Prefix="groundspeak" type="xs:string" minOccurs="0" msdata:Ordinal="8"/>
So given it is a minOccurs of 0, it doesn't have to be included if it has no value. The fact that it's included should mean that the reading process takes country and state to be BLANK rather than MISSING. No drama, just a bit rubbish.
As there are no logs in the exported file, they are never going to show up as being found by you at GCA. We use the log and the name to determine your finds. So without logs, this will create a list of geocaches that have no useful log data.
As far as how "you" are seeing your logs in GSAK, you may have an additional macro running that gets the logs from the GC site as the tool certainly contains no information that tells me that you or anyone has found or not yet found it.
A different problem, as has been pointed out, is that a lab cache with 10 points will show 10 markers. I can't tell from the file which is the "main" or starting point so each one is seen as a separate lab cache with no connection between them.
To be honest I would like to incorporate lab caches. This GPX file is however, a mess, somewhat hacked, a bit rubbish and possibly not stable. I don't want to pollute our DB with garbage that is hacked from outside the GX site.
If GC ever produce a GPX file for a lab cache we can revisit it, but for now, this doesn't look like it's good enough to use.