oh yeah, this is a bit of a gap in NIP-01 filters spec... currently it's undetermined behaviour, if you ask for a limit of requests or there is more that match your filter than it will deliver (most relays hard limit to 500 per filter) then how do you know if there's more? it's a guessing game, the only way to avoid this problem is to set big limits and make tighter boundaries on the request filter (times or numbers of kinds etc)

i think that the relay should send one last message tied to a subscription indicating "..." when the filter stops before the data does, is just a matter of even running one more than the limit and if there is another, then send "..."

the ordering of replies implicitly tells you how to form a request, as usually it's based on when the event was received and so you just repeat the query but bring the "since" timestamp to the last one found to be sure to be sure