Given that I've been busy discovering that the Browser can't see 'compressed' dirs/files, I haven't yet had a chance to see how well a symbolic link (yes, MSoft finally supports those now) works with C3 installations to redirect the install from off the C: drv to the location of MY choice. Rather than being a guinea pig yet again, I'm hoping that someone may have already done the experiment and would be willing to share their results. By and large, everything worked just fine with 'links' for me for years now though some vendors (ie Steam) clearly stated that while a MSoft feature they didn't support them, though they worked just fine. 
 
I suspect the C3 would create it's own dir's during the install and thus overwrite anything previously setup as a link, and this could be a problem for the auto-updates as well. If the C3 used existing linked dir's for install's if they existed, then this might be a reasonably clean way to handle the lack of C3 installation location issues. 
 
C3 clearly already does some merging of files into existing dir's, like the Contents, etc. However, which ones is not at all clear and is way beyond the Cog settings. Again, doc's and a help entry are needed to assist in installation of the product.
 
 
 

If are referring to the mklink command to point to new drive locations... scook (our resident guru) has recommended it multiple times to me and others so I can only assume it works. I haven't gotten a chance to try it yet and I'm still contemplating whether to use that method or start from scratch but it does look more convenient. scook has never steered me wrong.

Yep, that's the one. There is a RClk Context Menu addition that makes it pretty simple. I'm wondering about how long the link might persist and if it would support updates. A one-time transfer seems pretty pointless. Good to know that it is at least being looked at, so thanks.

I have not tried a full install using mklink (with /d or /j) but expect it would work. I have never used a compressed drive and have no idea what to expect if a compresses drive is involved.

Please let me know how the mklink options work out. Inquiring minds want to know!
The discovery of 'compressed' file issues has made me very nervous about Cakewalk 'custom file handling' capabilities and how it might interact with OS evolution.
 
I compress pretty much everything routinely. I've got 10 internal SCSI ports that are already mostly full (though 2 are being saved for m-SATA eventually). I pretty much fill my 6 external USB3 ports with Bu devices as well, though try not leave them on-line. I can kind of see maybe not compressing audio/video for real-time edits, but I don't need anymore drives, so I compress. ~2.5TB on-line at about 70% utilization. I'm still recovering from the premature death of my new 'primary' BU 3TB USB drive, so now I've got 2 to just back themselves up.
 
 
I was hoping to not have to do yet another SPro install this week. 
 
 

I have used directory junctions to relocate sample libraries and other data for applications from Cakewalk, Toontrack, iZotope, Native Instrument and others. Subsequent updates and installers have always worked as expected. I don't plan on installing Platinum again or experimenting with compressed file systems.

If we are talking about VMWare here, I tried and failed a couple of years ago...
I wouldn't use an actual compressed drive unless it has been decompressed first. Maybe technology has moved on but for DAW fast read/write purposes I found it sadly lacking...

The compressed drives are for the .exe's and config info, like plug-in menu layouts. My drives are fast enough that I haven't had anything choke on audio (so far), but I've got lots of RAM as well. Still, I agree, most audio, particularly anything that might need to get loaded or streamed from disk realtime, should be uncompressed. I've mixed feelings about some the 'huge' sample lib's out there these days since these usually pre-load the active samples anyway. Even the Wusik v6&7 are like ~15GB each these days and it's not even fancy stuff. Naturally, they don't go on a SSD either, even if they are basically read-only after the install.
 
Decompressing takes essentially no time/RAM/CPU relative to what's required if a disk fetch is needed anyway. Streaming successfully is much more a question of how the program is buffering data anyway.