This is not a bug that breaks normal use of org-id, but it may affect downstream uses.
An example is my package org-node, which checks file names known to org-id, and combines that with other sources of information, to build a big file list. This list is automatically de-duplicated because I can normally assume the names are abbreviated. However, reading the source, it seems that it will not ensure this if `org-id-locations-file-relative` is t. Then `org-id-locations-load` merely uses `expand-file-name`. So a path that used to be ~/org/file.org becomes /home/me/org/file.org after loading back from disk. This can be tested by evalling these sexps (if you replace "/home/me" with your own home): (org-id-add-location "id1234" "/home/me/org/file.org") (gethash "id1234" org-id-locations) ;; => "~/org/file.org" (setq org-id-locations-file-relative t) (org-id-locations-save) (org-id-locations-load) (gethash "id1234" org-id-locations) ;; => "/home/me/org/file.org"
