As we move projects from disc to network and so on, 'arbitrary_path' can change, but the relative link between a component and its draft is not changed, at least as far as we don't change 'DRAFTS' name.
We use the default LinkMgmt.txt configuration, so no break link should occur if we just change 'arbitrary_path', since the RELATIVE approach should work fine. In fact, in previous versions of SE, even changing DRAFTS with another name was fine. SE seemed smart enough to find for a link inside a draft in the upwards folder before trying to get the absolute path.
From our experience, SE has lost that 'look upwards' behaviour and, even more, when the RELATIVE paths have not changed, sometimes (not always, weird!) the links are broken and we must make a full re-link.
We have tried a dirty trick in order to get back the 'look upwards' of the past, editing LinkMgmt.txt this way:
BEGIN SEARCH PATH
END SEARCH PATH
As you can see, we have added instructions to look in the up folder until two depth levels (sometimes we make subfolders for diferent drafts, so a second level in the tree is useful). To our surprise this works :-D, althought, as I said, nothing of this was ever needed in previous versions. SE managed to reach links placed in upper levels naturally.
Now comes the amazing part of the story: with the LinkMgmt.txt as shown, whenever we try to launch SE and open documents through the API, the whole app gets freezed. No errors, no exception, no messages. SE gets freezed and the document never opens. If we have manually launched SE before, so it's not opened from the API, we can skip the freeze most of the time, but not always.
If we restore LinkMgmt.txt to its default, all works fine.
Conclusion: launching SE and opening documents from the API does not like our 'seek upwards' tricky directives, which in fact work superb when working manually, althought were not never needed in older versions of the software.
The opening and loading of documents it's done by means of the typical API methods: