Re-Organisation of Content: Absolute and relative paths

Through the years I got a really huge content database - I used SSDs for better velocity, but the capacities of the SSDs were not so huge (compared with common HDs...); so I now have my content in several Libraries - I just had to open the fourth . It's possible to work with these several libraries, f.e. the search function of the CMS includes all files - and I have some vague ideas where I have to look for which content. But of course the content structure is far away from being optimal. For example: it would be much better to have the files sorted by Genesis generations instead of having G2, G3 and G8 files in several of my "My Libraries" - if I continue to work with the several SSDs/Libraries. Another idea would be to "re-unite" all Libraries on a big HD; then all Genesis generations files would be re-united and sorted, too - the only question in both scenaries is: Would the installed content work within a new absolute file path structure?
I think there is no absolute file path given in the installation manifest files (and of course I can copy the content of an installation archive manually to a Library of my choice...). So I would guess, if I open a character or wearable *.duf file in a specific directory/path (f.e. My Library 3\People\Genesis 8 Female\Characters\Pei) it would try to load the necessary texture files from lets say the "textures" folder within the same main directory/path (in this case My Library 3) of the *.duf file? Then of course a re-organisation would be possible - I guess that should be the case, because I don't see how an absolute path should get into the *.duf file if I just copy the content into the Library without using the DIM.
But before I dare to try, I ask the community and the experts ...
Thanks for your advice.
Comments
The DIM Install manifests dos tore absolute paths (they have to know where the file is to uninstal/update it), as long as you are using DS 4.9+ the Content Management System doesn't, and internal refrences (to textures, geometry, and so on) should always be relative. You can tell DIM to use the current install path for updates (click the gear icon at top-right) so there would be an issue only if an update needed to remove and not replace a file.
Dear Richard, thanks for the explanation - I should have realised by myself that there is not an absolute path "a priori" in the manifest files, but of course after the installation by the DIM. Of course that's the way DIM is working; and I of course change the current install path every time when there are updates for a product to that "My Library" path the product was initially installed and never had problems. And I moved some "large" products without any problems from one Library to a new one by de-installing and re-installing. (The last product I purchased marked a new file size record: "Now-Crowd Billboards-Party Time"; I could start the download only after I had arranged some fresh space on the hard disk with the DAZInstallManager folder and after I had founded a new Library
...)
But my question; or my concerns were more about the products which were not installed via the DIM - the old files from DAZ which came as *.exe; and products from other sources like Renderosity. I know that there is a way or product to get such files DIM-compatible, and I tested it sucessfully - but that's a lot of extra work; so in the end effect I continued with the easy way and just copied the files in the product archives manually to the current "My Library".
But if the internal references are relative paths (and indeed that should always be the case...) my plan to re-unite the several Libraries to one Library should work. Of course I would then have to re-indexing all files by the CMS; and I would lose the possibility to de-install single products via the DIM - but updates should work with the new re-united Library/path as installation target. Right?
Right, all your old Bitrock installed content and zips from other stors should not be affected by moving the content directory (ecept that if you choose to have an uninstaller for the Bitrock stuff that will no longer work).