I do test , if the program is free, but this one isn't, so cannot test.
In that case, you can simply attach the patch to the Wine-Bug report and ask the user to test it like I did here: https://bugs.winehq.org/show_bug.cgi?id=54623.
I think it's just fine to add the stub so that user can test it in the next
release to see if it helps workaround the bug and report back.
I don't think this is fine as users often abandon bugs. Another user might file a bug report for another program that happens to call the stub. The stub can make it difficult to pinpoint the cause of a crash or issue, especially since Wine is rife with stubs. Of course, there are functions which are reasonably safe to stub.
However, in this case, it's obvious a stub does not help. Since the function is creating something, it's safe to assume the program might attempt to access the object. Returning failure like E_NOTIMPL is often no different than returning success like S_OK since a lot of programs don't bother to check for failure and assume functions always succeed.
Apparently you have access to this program, and already knew the answer.
Please share this info in future in bugreport then.
I had access to the program when I was working on it. Well, if you read the info in the bug report you would know the bug started after adding in MediaControl. I sent multiple patches for Roon. I would have sent an MR for a simple stub if it helped.
Also, sharing the info in the bug report is apparently pointless. See the previous bug: https://bugs.winehq.org/show_bug.cgi?id=54623
The info was ignored and an MR created nonetheless: https://gitlab.winehq.org/wine/wine/-/merge_requests/4579
Lastly, I'm not paid to work on Wine. I have no obligation to share anything, especially since a lot of bug reporters are unappreciative and even hostile.