If I understand correctly, you want to make playlists portable by associating each item with enough metadata to allow identification even when some metadata, such as filepath, changes.

Playlist and metadata are separate things, and coupling them is not good from an architectural perspective (redundancy/denormalization). The two can still be related, even in a single file: relational database. (plug: I'm working on http://jstimpfle.de/projects/wsl/main.html)

Sketch to make more clear what I mean:

    {
      "metadata": {
        "buss_und_reu": {
          "filepath": "Bach/Matthäuspassion/Buss_und_Reu.mp3"
          "composer": "Johann Sebastian Bach"
        },
        "highway_to_hell": {
          "filepath": "ACDC/Highway_to_Hell.mp3",
          "artist": "ACDC",
          "sha512": ...
        }
      },
      "playlists": {
        "mypl": [
          "buss_und_reu",
          "highway_to_hell"
        ],
        "mypl2": [
          "buss_und_reu"
        ]
      }
    }

This is more normalized, less redundant. Of course other schemes are thinkable, for example storing each playlist in its own file, but this way metadata and playlists will more quickly get out of sync.

The library I'm working on allows automated conversions of such hierarchical data to/from relational databases, so data can be viewed, and even stored, as JSON, while integrity is checked based on an relational schema - something like

    % TABLE Track trackid
    % TABLE Filepath trackid filepath
    % TABLE SHA512 trackid sha512
    % TABLE Title trackid title
    % TABLE Composer trackid composer
    % [Declare also domains, keys, and foreign keys here...]