0) There is no time window
1) Nope
2) qa-include/db/events.php
How updates are handled is a bit complex. Let's take a top-down approach.
There are some actions that register users as "following" certain posts. For example, creating a question. Whenever something in the question changes the change is registered too for the user. Those changes are the ones displayed in the updates section.
Considering the amount of changes that could be registered, tables would be huge. So the core instead of keeping the whole history of each changes that should be "notified" to each user it just keeps the last X changes for each user. X is, by default 5, but can be changed to something else at any time (look for QA_DB_MAX_EVENTS_PER_Q in qa-include/db/maxima.php). This means that each time an event is added that exceeds that number the core checks if the amount of events for that question exceeds that number and deletes the remainder, if any. So it doesn't matter when those events happen but rather how many have happened.
To make things a bit more complex, there are times that events for a given user are added but are not targeting a particular question. Even in these cases a clean up process is still run. The process does not use the QA_DB_MAX_EVENTS_PER_Q but rather uses an almost (?) fixed value to limit the amount of events for the given user. So if the user exceeds Y events associated to them, regardless of the entities (e.g., questions) they correspond to, the clean up process removes the remainder that exceeds Y. Y is, by default 50, but is not a fixed value to change in the code as the previous one but rather a setting. The thing is this setting has no UI component associated so it has to be changed programatically this way:
qa_opt('max_store_user_updates', 60);
If this wasn't complex enough then you should also take into account that there isn't only one single tracking of events as explained before. In fact, events are tracked at a user and at a question (actually, entity) level. The only difference between the two of them is that the first one also adds the user. All events are tracked at the entity level but, whenever an entity receives a certain amount of subscribers, then they stop being tracked at a user level. Explanation for this being this way is long and can be found in qa-include/db/favorites.php but, in short, it is just performance. The important thing is that these two different trackings are performed in two separate tables and both are cleaned up in a similar way.
The cherry of the ice-cream is that there are certain situations in which a random user is taken to be target of a clean up.
Conclusion: you wish there was a time window, don't you? All I said might be slightly inaccurate as I do not know all the business rules related to the events but I guess you get the general idea and how to increment or decrement the amount of updates, regardless of the impredictibility of the amount of updates a user would see.
