For me a stubs that allow a programs to properly run further is a win-win situation as long as the stub stays on it's side.
How is it a win in any way? You're not making the program actually work, and you're adding more useless code to the repository. Nor is it contributing particularly interesting work; stubs are not hard to write.
The "In cases where someone is actively working on a proper implementation, it also often gets in their way." parts is not really a big deal as wine contributors already maintain patches on top of the latest code-base for multiples month already, adapting a patch on top of a stub is really not a big deal, I have dealt with far worse.
Those are not really a problem, sure it can take a few minutes, bit it's not a big deal, and almost everyone doing an MR to Wine has to deal with it already in some way.
Sure, it's not hard, but it's a pain. I've had to deal with that before and I'd really rather not again.
If you still really want to go to the way of the "no stub" route, proper guidelines should be there in written form so there won't be 4th MR opened with the same stub, as most peoples would still think this would be useful to spend their time on this and are likely to open many more of the same MRs for nothing.
Sure. Where would you suggest to put this advice?
I really want to try and take a look on how to do a proper implementation though, as I have a sneaking suspicion it's not as complex to implement as it seems.
It's actually pretty much impossible. The licenses are encrypted with a private key which is distributed as part of the OS, and which we cannot legally redistribute.