The JSPF spec may only be by example, but it clearly shows that for extension data, the value is a list of arbitrary objects:

...
"extension"     : {
  "http://example.com/app/1/" : [
    ARBITRARY_EXTENSION_BODY,
    ARBITRARY_EXTENSION_BODY
  ],
  "http://example.com/app/2/" : [ ARBITRARY_EXTENSION_BODY ]
},
...

This is also borne out when using the XSPF-to-JSPF converter linked in the spec.

However, ListenBrainz' playlist data uses a single object as value at both the playlist and the track level, which violates the spec:

...
"extension": {
  "https://musicbrainz.org/doc/jspf#playlist": {
    "algorithm_metadata": {
      "source_patch": "top-discoveries-for-year"
    },
    "public": true
  }
},
...
"track": [
  {
    ...
    "extension": {
      "https://musicbrainz.org/recording/": {
        "artist_mbids": [
          "67468e38-0c90-4318-b2d2-0c18b7b1e144"
        ]
      }
    },
   ...
  }
],
...

In addition, the track objects have a single URI value for the identifier field, but the spec has this (and location) as a list (because the XML version allows these to appear more than once).

(There is also the fact that the XSPF spec explicitly says that the annotation field is not allowed to contain markup, so maybe the current annotation should shift to an extension field, but that does not impact code deserializing the data.)