Distributed predicate computation on event stream
Impossibility result #1: dropped events
The problem cannot be solved in general; there is no way to guarantee that your requirements will be met if some events are dropped (i.e., not received).  Consider first this stream:
e1 = { name: Jhon, timestamp: 1 }
e2 = { name: Jhon, timestamp: 4 }

where the algorithm sees both events.  Next, consider this stream:
e1' = { name: Jhon, timestamp: 1 }
e2' = { name: Pete, timestamp: 2 }
e3' = { name: Jhon, timestamp: 3 }
e4' = { name: Jhon, timestamp: 4 }

where the algorithm sees only the events e1',e4' (the other events are lost and never received).  You might notice that what the algorithm sees in both cases is identical, so its outputs will be identical in both cases.  However, the correct answer differs in these two cases, so there is no hope for an algorithm that always produces a correct output.  (The correct response in the first case is to produce no notifications; the correct response in the second case is to produce two notifications, one to indicate that the predicate is false after receiving e2', and one to indicate that the predicate is true after receiving e3'.)
It is not clear how to adapt the requirements to deal with this situation.  The only plausible solution I can see is to say that the notifications that are produced should depend only on the received events, not on the events that are sent.  This is equivalent to specifying that events cannot be dropped.
Impossibility result #2: re-ordered events
You state that you must be able to handle re-ordered events, without storing all events in memory, and with arbitrary re-ordering. However, these requirements are incompatible: that is impossible to achieve.  Consider a long sequence of events with timestamps 2,4,6,8,10,12,...  At the end of the long sequence of events, if an event with an odd timestamp arrives, the only way to be sure you can handle it correctly is to store the entire history of past events (or past states of the object).
So, you're going to have to relax the requirement about re-ordering as well.  Perhaps you're willing to store all events in memory forevermore.  (If so, you have a solution.)  Perhaps you are willing to impose a bound on re-ordering, e.g., no event will be delayed by more than 10 minutes.  (If so, you only have to store history for the past 10 minutes, and everything older can be deleted.)  Perhaps something else makes more sense in your particular situation.
But the one thing that is not an option is to impose all of the strong requirements stated in your question, and require an algorithm that is always correct.

I'm not aware of any literature on this and I don't particularly see any reason to expect there to be any.  It's a very specific set of requirements, and it looks to me like the resulting task is either trivial or impossible to solve.  Those usually aren't the kind of problems that tend to be studied in the literature.  Perhaps you might be interested in persistent data structures, but that's just a fancy way of storing the entire history of events, which you said you want to do; and you don't need a fancy data structure to do that in your particular situation.