The problem is only affects new compiler, that is not used (yet) to produce release binaries.

Wenn LibreOffice is compiled with MSVC 14.0 (aka VS 2015) that cannot be downloaded, as the compiler is used for building releases is MSVC 12.0 (aka VS 2103) the produced MSI installer is broken, meant it's installing the C-Runtime in wrong directory, for example, for 64bit version into C:\System64, where the DLLs cannot be found (obviously). Trying to start LibreOffice after this installation, reports this error:

"
The program can't start because VCRUNTIME140.dll is missing on your computer.
Try reinstalling the program to fix this problem.
"

Inverstigation results:

Since MSVC 14.0 merge modules shipped with the compiler, e.g. Microsoft_VC140_CRT_X64.msm changed the directory table definition. Particularly the directory name was changed from:

MSVC 12.0:

    System64Folder: TARGETDIR
    System64Folder_amd64_VC.363ED482_721F_3A34_85B3_A96CD936D64F: System64Folder

MSVC 14.0:

    System64Folder.363ED482_721F_3A34_85B3_A96CD936D64F: TARGETDIR
    System64Folder_amd64_VC.363ED482_721F_3A34_85B3_A96CD936D64F: System64Folder.363ED482_721F_3A34_85B3_A96CD936D64F

What is missing in the currently implemented merging module merging process in LibreOffice installer,
is rendering the Custom Action 51 (Property Change) event in the resulting MSI CustomAction table,
as defined in "Authoring Merge Module Directory Tables" specification, in
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367787%28v=vs.85%29.aspx:


"""
When a predefined directory is included in a merge module, the merge tool automatically adds a Custom Action Type 51 to the target database. The merge module author must ensure that a CustomAction table is also included. The CustomAction table may be empty, but this table is required to exist in the target database and ensures that the modified predefined directories are written to the correct locations. For example, when a system directory is included in a merge module, the merge module author must ensure that a Custom Action table exists.

Note that the matching algorithm for the generation of these type 51 custom actions only checks that the directory name begins with one of the predefined SystemFolder properties. It does not verify that the directory name exactly equals the directory property. Any directory beginning with one of these standard folder names gets a type 51 custom action, even if the rest of the name is not a GUID. Authors need to take care that this does not generate false positive matches, and unintended custom action generation, on derivative primary keys that begin with one of the SystemFolder properties.
"""

For example, WiX Toolset, for the same merge module mentioned above, correctly renders
two Custom Action when decompiling it with melt.exe utility (when translated to their
WiX source representation, wxs file:

   <CustomAction Id="System64Folder.AF4EABEE_4589_3789_BA0A_C83A71662E1D" Property="System64Folder.AF4EABEE_4589_3789_BA0A_C83A71662E1D" Value="[System64Folder]" />
   <CustomAction Id="System64Folder_amd64_VC.AF4EABEE_4589_3789_BA0A_C83A71662E1D" Property="System64Folder_amd64_VC.AF4EABEE_4589_3789_BA0A_C83A71662E1D" Value="[System64Folder]" />

And it can be seen, from the resulting MSI, that these lines are appended to the resulting MSI
in the custom action table as:

   Action    Type    Source  Target  ExtendedType
   s72    i2      S72     S255    I4
   CustomAction   Action
   System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1    51      System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1     [System64Folder]        
   System64Folder_amd64_VC.3CFBED52_9B44_3A4D_953C_90E456671BA1   51      System64Folder_amd64_VC.3CFBED52_9B44_3A4D_953C_90E456671BA1    [System64Folder]

This step missing in LibreOffice installer merging merge module code.