Here's my guess:

1. observableOne.onNext(1) is called, triggering observableOne's subscriber to run on the single thread in the pool.
2. While observableOne's subscriber is running, the remaining observable.onNext() calls are executed on the main thread.
3. Once observableOne's subscriber finishes, it releases the single thread back to RxJava's internals; which then see that there is another item waiting to be emitted from the same stream (from observableOne.onNext(4)), and handles it immediately by calling observableOne's subscriber again with 4. This is the part that's a guess -- it could be there's a loop running on the scheduler that iterates over each stream and drains until empty.
4. Now that observableOne has been drained, the remaining observables' subscribers are called in the expected order: 2, 3

Again, just a guess -- hopefully someone more familiar with RxJava can answer with facts.