I dont know unix/linux well enough to talk about its linking.
but on windows there is a technical difference between a junction link ( mklink /J) and a symbolic link ( mklink /D)
A junction works as long as the target folder itself "(new_parth)" is not moved.
A symbolic link (/D) breaks if the full path (including parent folders) changes. basically if something changes it breaks.
And junction links have better compatibility with Windows and applications.
Some software and tools (especially older ones) treat symbolic links as shortcuts but treat junctions as real folders.
Junctions should not require special permissions (Admin mode is often needed for symbolic links).
There is actually 3 main types of linking on windows. /D symbolic link, /J junction link, /H Hard link
All have their own pros and cons.
Actually, that creates a potential terminology confusion.
I have been both a Windows admin and a Unix and Linux admin, that is why I know that those things, as well as the way Powershell does some stuff, come from *nix (well, also because it was admitted by the Microsoft people themselves

, including the lead of the team that created powershell).
But you reply also tells you why I personally don't like to use that kind of stuff - the "breaking with moving the paths" part - at that point, I prefer using folders as "mouting points" (which in reality are possible even in Windows server since some versions ago, honestly I am not sure anymore about the client OS, I remember vaguely Windows 10, thus I would expect 11, also would do it, but I am not sure I ever used it) .
In that, linking on *nix seems more resistant (hence my reference to potential terminology confusion).
Yes my example i do assume you're using the default location.
therefor it may or may not be an option for you.
D
Well, any additional and updated bit of information can be useful, but actually, it was not at all for me, I don't need it for DAZ - but I am not the only person in this forum or the World, maybe our exchange can be useful for others as well.
I was suggesting it, because I have already seen in the past the problem when people give instructions without thinking about the situation of the one that has to run them, and/or without abstracing from their own situation.
My job in the past, even recent, has been also both giving instructions, and (try to) recover the mess when someone followed instructions without having the elements to adapt them.
"My way" works perfectly fine for me, I have two NVME disks, each with more than one library path, so I can separate stuff installed using DIM, stuff installed manually, and stuff installed or created with other utilities or e.g. when converting items between generations.
By using the hard drive letter mapping and just telling Daz the various directories, means I can even have more than one computer with Daz installed at different locations, without need to get extra disks and duplicate the library.
I just make sure the Daz files and database are updated on both side (well, may need also to copy the user config directories if I changed something), move the disks between the machines making sure the drive letters are the same on both, then both DIM and Daz works fine.
Till when Daz does continue to work the way it works and the postgresql versions are the same, once it is installed, brutally copying over (or better, deleting and copying over) works fine.
Actually, even if the postgresql versions were different, it could still be possible to do a backup of the database, at "worst" in sql format, and restore it in the other machine, it even comes directly with pgadmin included.
Or since already from some versions DAZ comes as setup and not a DIM package, the "update over previous installation" is also a possibility.
What is the exact best scenario depends also on the plugins installed, I have done more than one variant.
The only time I got screwed up was once at the start that I did an upgrade without doing the backup first, naively thinking one could do a rollback - learnt by my own mistake not to trust Daz (and their support, after some interactions) on certain aspects ;-)