I think at this point we need to review the use of wimbootcompress.ini.
To me this file is needed only when capturing but I read different understandings on this point.
As a whole if I understand correctly, apart from a different compression scheme (XPRESS 4k chunks) and a wimboot (XML) tag in the wim file, the capture wim file is not much different from an "ordinary" wim file.
Thus, it seems that files inside the wim get some sort of a flag that will make a difference when restoring/applying? (i.e bootmgr, bcd, etc).
The only differences between a WIM captured in WIMBoot mode and one captured in the default mode are that the WIMBoot mode adds <WIMBOOT>1</WIMBOOT> to the XML data and also uses XPRESS compression with 4096 byte chunks. I was unable to detect any per-file flags. DISM/WIMGAPI appears to use the [PrepopulateList] section of the file \Windows\System32\WimBootCompress.ini inside the WIM when applying to determine which files will be extracted normally, not as WIMBoot pointer files. So I made wimlib do the same thing, and yes you can simply replace this file in the WIM image instead of completely recapturing. I will double check that DISM/WIMGAPI really has the same behavior.
Note that the <WIMBOOT> section and XPRESS compression are not, in fact, required for creating pointer files to the WIM. With wimlib (but not WIMGAPI/DISM), you can take a WIM captured in the default mode (without --wimboot) and apply it with --wimboot, and it will still work. The file \Windows\System32\WimBootCompress.ini will retain the same importance, however. In addition, XPRESS compression with 4096 byte chunks may be better suited for backing files than LZX compression with 32768 byte chunks.
It would be possible to add a --config option to apply, to override \Windows\System32\WimBootCompress.ini in the WIM image. I'm not sure this would encourage good practices, however, since if you have to use it then I think that would mean you captured a custom WIM image with the wrong configuration, and it would be better to fix the WIM image itself by updating \Windows\System32\WimBootCompress.ini.
Last, reparse points files cannot be dealt with without the MS WOF driver unless you deal with them at the MFT level.
Well, kind of. At the programmatic level, you can open a reparse point with CreateFile() with FILE_FLAG_OPEN_REPARSE_POINT, then you can get, set, or delete the reparse data using DeviceIoControl(). But yes, from a practical standpoint if you have a reparse point that is not handled by any running driver, it will appear as an inaccessible file to all programs that aren't designed to deal with reparse points specifically.