Many games come with their own D3DCompiter_47 DLL and VCRedist files, but those are actually heavily out-dated Windows files... I know that if D3DCompiter_47 and VCRedist DLL files within game directories are either renamed or deleted, then the game will use files with same filenames from Windows\System32 directory, where newer and OS-native files reside. For example, Witcher 3 ships with D3DCompiler_47 6.3.9600.16384 . If I rename that file, the game will start using my OS native D3DCompilter_47 build - 10.0.14393.1715 . Witcher 3 also ships with Xinput1_3.dll file. I renamed it, then took (newer and OS-native) XInput1_4.dll file from System32 folder, copied it into Witcher3.exe directory, renamed it to XInput1_3.dll and the game still worked without issues. I have not noticed any issues in any games when forcing them to use newer OS-native DLL files, but there could be negative or positive consequences I am not aware of. Does anyone know?
Tested new VC++ files and blink player dll to Fallout 4 folder, no problem so far. Ghost Recon Wildlands comes with TH2 d3dcompiler_47 (wow that's old) and i replaced it with one from my system32, no problem, finished the game all the way from start. Maybe not all games will be fine like this but if it works, it works.
You are rolling the dice when doing this, but usually, you should not have a problem. Truth be known, in the past, this was a quick & dirty method of patching unresolved issues in older games. Even in newer games, this can sometimes resolve issues. I recall one game in particular (forget the name, but recall the gameplay) when such a method actually resolved screen refresh rates (replacing dlls with newer). But you are taking a chance when doing this as I also recall nearly finish a game and being unable to complete the final boss (game crashed when the boss died).
Typically, if a game comes with a particular version of a dll, it's because the executable was linked against that particular version. By replacing the libraries that the executable was originally linked with, with newer files, you run the risk of the library either not having the expected exports, or, having significantly altered behavior in the export that the game's executable is linked for. That's why you're running a risk of causing issues with games and programs - unknown behavior/compatibility between library versions. For old games, however, I do recommend trying to use WineD3D, which replaces old DirectX 7-10/11 dll's with openGL-translating code, thereby allowing old games to run at higher resolutions, or more stable in their native resolutions.
The version number only reflects the Windows SDK it was bundled with. That library hasn't changed since 2010. You can use either version, it's all the same thing.
Both file version changes and file size changes are simply consequences of bundled SDK? What about Xinput? I renamed the native 1.4 version to 1.3 inside some games' folder and those games now use 1.4 (renamed to 1.3). I think that may be reducing input lag or something like that. Native (and old) 1.3 is much bigger in size than native new 1.4.