I strongly suspect that combining async streams will prove to be a problem in practice, whether we resolve glitches or not. This article requires quite subtle reasoning about async systems. In my experience this type of reasoning is rarely done effectively on real life projects.
I am not criticising Rx, I am interested in Rx. But I am always concerned when a project/community starts producing articles on very subtle topics and claims 'x isn't a problem if you just understand it properly'. Here properly probably means deeply, and deep knowledge in software is scarce. There are too many things to know, to know many things deeply.
Let me look at one example (and please comment if I'm really not understanding something).
So we consume, asynchronously, two streams. Because they are asynchronous we might hit some point where it's a bit uncertain where two outputs are related.
errors ---e1----e2------------------
userActions -u1------u2------------u3----
analyticsMessages ---e1u1--(e1u2 e2u2)---e2u3--
That's a good example, and we fixed that problem with 'errors.withLatestFrom(...'. But, since we are asynchronous don't we also have to worry about this scenario. errors ---e1-------------------e2--
userActions -u1--u2--u3-u4-u5-u6-u7-u8--
analyticsMessages ---e1u1---------------e2u8--
Now, let me clarify what happened here. The error occurred after u2, but the errors thread got descheduled and the userActions thread kept on processing. I am not certain exactly what to expect from 'errors.withLatestFrom(userActions,...' here but I suspect that 'e2u8' may be the expected output.So this error reporting system is fundamentally unreliable. If this is correct then I would say that combining Rx streams is not appropriate for this use case. This also suggests that although we managed to get rid of our glitches we still produced a terrible piece of software.
Do I have to wrong end of the stick? (The answer was yes, but it was good anyway)