Maybe I will add it as an answer so you can accept it like you say - and maybe upvote. Then just let the bounty run out - I don't think it will work since you don't have the reputation yet.
I don't have time to read this in detail at the moment, but please have a look at this answer: WiX-installer With Configurable Feature Directory (towards the middle, and also the rest of the answer if it looks relevant). These are "feature directories" that can be linked to an actual directory property as described in the link.
The sample above uses the WiX Mondo dialog set. I describe setting up a minimal WiX compile with the Mondo dialog set here. Essentially a "Hello WiX" project, but you have this down already. Just adding it in case someone else may find it helpful.
UPDATE: My brief testing seems to show that such feature directories are persisted by the system for most installation modes, but not for major upgrades. To read the previous settings for these custom folders, you need either an AppSearch or a custom action I'd say, and you should make your setup persist the directory properties in the registry.
Some pointers
These are just some suggestions from quick testing. Please, as always, test thoroughly yourself. There is a lot of what I call "conspiratory complexity" in Windows Installer - problems surface unexpectedly - for example when you try to deliver an upgrade.
Persisting your properties in the registry during install (your feature directory properties):
<!--Put this inside a component-->
<RegistryKey Root="HKLM" Key="SoftwareMyCompanyMyApp" ForceCreateOnInstall="yes">
<RegistryValue Type="string" Name="MYCUSTOMDIR" Value="[MYCUSTOMDIR]" KeyPath="yes"/>
</RegistryKey>
<!--Put this inside a component-->
<RegistryKey Root="HKLM" Key="SoftwareMyCompanyMyApp" ForceCreateOnInstall="yes">
<RegistryValue Type="string" Name="MYCUSTOMDIRTWO" Value="[MYCUSTOMDIRTWO]" KeyPath="yes"/>
</RegistryKey>
And important!: this will write to HKLMSOFTWAREWOW6432NodeMyCompanyMyApp - the 32-bit section of the registry on a 64-bit OS. You may need to write and read from the 64-bit section. If so, just add the Win64="yes" attribute to the Components and the RegistrySearch elements.
A link: http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/
Next read them back with a registry search:
<Property Id="MYCUSTOMDIR">
<RegistrySearch Id='MYCUSTOMDIR' Root='HKLM' Key='SoftwareMyCompanyMyApp' Name='MYCUSTOMDIR' Type='raw' />
</Property>
<Property Id="MYCUSTOMDIRTWO">
<RegistrySearch Id='MYCUSTOMDIRTWO' Root='HKLM' Key='SoftwareMyCompanyMyApp' Name='MYCUSTOMDIRTWO' Type='raw' />
</Property>
In an ideal world this should suffice for your purpose. I did not have time to test what happens when these properties are set at the command line for an upgrade (which could happen).
To create a major upgrade for testing you can basically just bump up one of the first three digits of your version number and compile a new MSI (rename the old MSI in the output folder to preserve it) - and generate a new product GUID (unless you have it set to auto-generate, in which case the version bump is enough). An MSI version number should incidentally have only 3 digits to be compliant to MSI standards.
