[...] And honestly, there's not a lot you can do about it either. The game requires these DLL files to function because they've been marked as essential at compile time. If GOG should add support for XP then they basically need to maintain a dummy DLL file of sorts that have been coded to implement all the functionality of the real DLL file, but with none of the actual behavior. This means not only maintaining a separate development chain but also provide branch support in their download clients and spend QA time to ensure that the DLL file doesn't break the game in any way.
Ergo, supporting it actually costs money. Money that the very small percentage of XP users don't cover.
I'm no coder, so don't quite understand why it can't be addressed with a "if... then... else" condition in that one and only .dll file, and requires instead a separate development chain and everything else you listed as a result of that. Note that I'm not referring specifically to Win XP, or GOG adding support for it, just making titles DRM-free without breaking whatever native compatibility an original release supported, with the full disclaimer that in the case of "else" one would get the DRM-free experience without any of the GOG Galaxy features.
Because if I understand the reason for the incompatibility to begin with then it's more underlying that that. Microsoft have done a ton
of architectural changes over the years. Because of this just the mere act of using Microsoft's modern compilers (which turn readable code into machine code) adds dependencies on these architectural changes. Those changes have been backported into Windows 7, 8.x and various Server operating systems, but not to XP and Vista due to their end-of-life support having expired.
For example, that solution of yours would most likely not even work since it still requires that the DLL file can be read and executed, which it can't on unsupported operating systems that can't handle the new dependencies.
As I previously mentioned there's ways around the issue, but all of those comes with a cost that simply doesn't pay for itself.
For example, we can assume that all GOG developers uses modern tools, right? However Fallout: New Vegas isn't a modern game, is it? So even if they attempt to change the source code of the game (which they must do to convert the Steam functionality into Galaxy functionality) then they most likely must import the codebase into a modern toolkit that it simply weren't designed for, which means changes will occur simply by the act of importing it.
The codebase was probably built using an older version of the Windows SDK, of which there's compatibility caveats of having multiple versions installed of (not to mention that few modern development tools are even tested or officially support outdated legacy SDKs). Hell, it's even built using DirectX 9, which is a part of the legacy DirectX SDK which haven't received an update since 2010 (and is therefor not officially supported on Windows 10 either).
The game and the source code for it is simply old. "Supporting" it fully without adding additional dependencies requires that all the development, compiling and testing are done on machines that match the original dependencies of the codebase. Then they also need to test it thoroughly on modern software to ensure that the old dependencies doesn't break anything. And even then they're at the mercy of Microsoft's whims, who can at any moment release another Windows 10 update that might break some of that old dependencies.
Old games that simply needs a wrapper or emulator around it (DOSBox, dgVoodoo, etc) is "simple" to fix since the actual source itself is untouched. But games that originally was built with other integrations (such as the Steam API in this case) either requires an excessively amount of time to reverse engineer the Steam API and implement a wrapper for it that translates inbetween Galaxy and the game (and even then we have the DLL incompatibility issue if the DLL file were compiled with a modern toolkit) or it requires actual changes in the source code of the game, and a recompile of the game itself, which will most likely mean modern tools aka modern dependencies.
There's no simple solution here. It's a highly complex issue that any solution of will have a cost attached to it. The most cheap option is to simply not support those OSes any longer, and therefor not even care about them when translating the game into being playable on modern hardware with modern features (Galaxy integration).