Actually, I had a test app already where it was easy for me to modify and test this scenario. It looks like Windows doesn't read from the sink event queue until after it has received the `MENewStream` events
I think that makes more sense. Is it clear that those are ordered steps, e.g. if you never send MENewStream does it ever start listening to the sink events?
The other thing I wanted to note (which may no longer be relevant) is that we would need to send the pending sample requests in to the very last transform (assuming there is one) rather than the source itself, as the transform may need multiple samples from the source to provide the sink with a single sample (and the number of samples provided to the sink should match the number requested). An example would be a H.264 decoder which might receive samples out of presentation order (such as when 'B-frames' are present)
Yes, that's another reason why proposed change is wrong I think. One more complicated thing to try is 2-input transform with two sources, feeding into a sink. Should it wait until all streams are created? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9716#note_125133