Later the event responder would detect out of order events and merge them.
Possible, but I'm not seeing much of this in my research.
Event sourced objects don't subscribe to events, so much as they observe streams of events.
For example, a typical rehydration idiom is that the persistence component will retrieve events from the event store and assemble them into a stream, before a repository takes the stream, rehydrates the event sourced entity, and offers that entity to the application component ready for use.
Having rehydrated the entity, we can propose a modification to it, collect the events that represent that modification, and then propose that the event store append these new events to the stream. The guarantee provided by the event store is that, if the events are accepted, you'll be able to retrieve the new version of the stream with the events in the correct order.
The usual way of supporting this requirement is that the events are paired with a sequence number, which can be used to order them within the stream.
You can think of these sequence numbers being version ids, but you should probably keep in mind that they are versions of the stream, not versions of the entity that the stream represents -- not all streams of events are associated with a domain object (think user events vs domain events, or projections that merge events from multiple streams).
If you are trying to pair event sourcing with pub/sub, you'll probably have a driver responsible for rebuilding streams. And that's OK, I guess -- you are basically creating a facade so that the subscription looks like an event store. But keep in mind that only past events get published to the event store; if you are loading an entity so that you can change it, you are going to need to append to the most recent version history anyway, so are you really gaining much by trying to reconstruct the stream locally? It's probably easier to ask the event store to bring you up to date.
Projectsions/queries are the odd corner case - you are interested in the contents of the stream, but not intending to append to the stream. In particular, it's generally OK if you are "behind" in time. There, the streams provided to you by the subscribed driver are likely recent enough to publish a new projection.
Pub/Sub can still be a useful way to consume events when you don't need direct event sourcing. A typical use case here might be a process manager: an event appears in our subscription, and determine that we want to start a new process manager instance. So the event handler will schedule a task to load a new instance of that manager. The process manager, itself being event sourced, will need access to its own stream to recover its own state; but the dispatch of the event to be handled by the process manager doesn't need to event source anything, and can run right off the subscription, no driver required.