That's the most help thing I've read on this topic. Thank you @zfigura, for your contributions (quite fond of NTsync) and specially for taking precious time out of your day to provide actual useful information. I really value this effort. I now see clearly the absurdity of the changes I am asking.
Your line of questioning was actually on point and designed to guide me towards the rights questions; why does the application intends to do with this information? Do I really need to implement everything just to trick the app to run? Does it even use the second node?
The answer is no. You right, 99% of my submission is garbage. I most likely only need to implement `GetNumaNodeProcessorMask` at most. I don't event need to report the second node.
Are there applications that need this or aren't there? You seem to mention a bug report; can you please link to it?
Here is the comment where I linked to the bugtracker issues I mentioned: https://gitlab.winehq.org/wine/wine/-/merge_requests/8970#note_115837
I am facing this issue when running forks of Open X-Ray that introduce optimizations to add concurrency into the S.T.A.L.K.E.R engine in an effort to reduce stutters. I can see those sort of optimization quickly becoming the norm in the stalker community so I feel it's important that our compatibility layer can support those. It only cares about the first node anyway which explains why my bogus patch still was able to apparently solve my issue: because no data is actually moved between nodes.
I'll take all your valuable feedback and try to come back with a clean version that checks all the requirements. It would actually be very cool if I can submit a production ready patch. Put it on my bucket list.
I'd like to also to present my apologies to anyone that been offended by my stupid proposition. Apparently I clearly needed that to understand why it's a bad idea and how it should be done.