To add to the expression of frustrations:

No OBJ file should have a generic name. Add your initials at the front.

dress.obj  is just lazy,  DkDrdress.obj (for a vendor DarkDream) would keep it safe from being over wriiten and you can even Park it in Geometries:Clothing with no need to add your own folder there.

If you do insist on your own vanity folders Stick with it for all your products. For example, If you insist on placing morphs in !vendor instead of Morphs do not use !vendorA for the next one.

Now for the good news, to repeat what has been said before:

If you have PP2014, these problems are potentially moot.

Everything can be put in a single folder.

Use relative paths.

The cr2 pp2 hr2 and .obj and .pmd  in the main folder.

• If you are in Hair and the figure is .cr2, you must double click instead of using the check box at the bottom. So you cannot replace, just add.  To replace, you would need to delete the existing figure first yourself.

The texures in a single subfolder (also a good place for templates) .   The Material poses in another subfolder. 

PhilC PZ3editor has a batch function that can edit paths for all files in a folder, so even 100 pose files can be path edited at one go.

One warning, if the folder has a .pmd file, park it somewhere else before batch editing the folder. It futzes up the .pmd contents.

Advantages:  all hair - irrespective of type can be kept together.  Same with clothing - prop or figure - all together. 

A character can have its .pz2, single morph spawned .pmd (if you wish to be efficient) textures, and material poses in a single folder. As an aside - how many teeth, sclera, eye color,  textures are needed? These universal textures can be in the main Runtime and shaired by all characters.

The texture addon products can be folded in with the original textures, and material poses added to the material folder, no more wandering arround looking for them.

Since everything is in a single folder and the paths are internal to that folder, the folder can be ported to amother Runtime easily. Have storage Runtimes and move what is in use to an active Runtime for scene assembly and rendering.