Long story:

The installer that used to come with Poser, for a mac, did indeed used to blow away installed content. If you were unfortunate enough to have your additional content in the same path the installer was trying to use. I tracked the bug to a BASH script in the installation. I even tailed the log file to watch it happen. From Smith Micro: "Our installer does not touch already installed content". Not quite true. I supplied the code and the log file. And they never did anything about it. Not sure if the same code is embedded in the 11.2 mac installer. The moral of the story (as someone already pointed out). Never keep your additional runtimes anywhere along the same path that poser installer wants to use.

FYI: the part of the installation that went wonky: It would install all the content into a temp directory. Remember that it was really a collection of a bunch of installers. Each would add its content to that place. The last thing the wrapper-installer would do was issue a unix "mv" command to move that content to "/Users/Shard/Poser Content" directory. The exact command they used in their bash script was "mv -f". Keep in mind that "mv" is NOT merge And when you overwrite a parent directory you are, in effect, blowing away all the children as well. The "-f" means "Do not prompt for confirmation before overwriting the destination".

I kept my content as:

/Users/Shared/Poser Content/7
/Users/Shared/Poser Content/10
/Users/Shared/Poser Content/2014
/Users/Shared/Poser Content/2014 Pro

Which was blow away when the installer overwrote /Users/Shared/Poser Content. Having "mv -f" in code is unforgivably sloppy (and dangerous) programming. I mean, what happens if the target is mistakenly "/Users" due to a screwed up variable in the script???

The script should have checked for the existence of /Users/Shared/Poser Content and should have checked that at least its first few levels of directories matched a poser install and had nothing extra. Or given the option to merge. Even my lamest BASH scripts do that. Reinstalling all the content (GBs, and using DAZ's old installers for some of it).... not fun. Did cause me to write a script that pulled the files out of all the DAZ installers and re-bundle tham as a simple zip. And a script that could take entire directories or runtime zips or figure out how to put the files into a runtime structure, for flat zips. And I move stuff around based on category. I keep those categories as labels (in extended attributes) in the zips. Lets me do things like use spotlight to search content for "poser, v4, character" and then pipe that into my zip install script.

The nice thing about unzip is you can unzip the content over content and it will, indeed do a merge. I de-dupe to hard links within each runtime. And I keep the runtimes sync'd to a server and my other machine.

And now I use:

 /Users/Shared/Content/Poser

And let the installer do its:

/Users/Shared/Poser 11 Content

and when it's done, I:

mv /Users/Shared/Poser 11 Content to /Users/Shared/Content/Poser/11

And I have set /Users/Shared/Content and /Users/Shared/Content/Poser so that even I can't delete them (without changing it purposefully)

Seriously... Having to reinstall GBs of content, especially those horrible DAZ installer bundled things... Yuck.

These days, I keep runtimes organised by category: common, gen4, la femme, a3, toon, and remove from the library those runtimes that aren't useful for whatever project I'm dealing with. It's been so nice this way, I don't dread the library like I used to :D

Also, things are moved together. I move morphs, poses, and mats to subdirectories under the object (figure) itself. Clothing is broken out by "tops. shoes, bottoms, costumes" and each contains it's mats. Much quicker to find stuff. I've found the library search to be essentially useless.