I noticed that many relays don't stop processing if a new REQ is received when the relay is still querying the past. The relay ends up pushing many "EOSE"s back. This creates an issue where the client can't know which filter set was finished in each EOSE.

Something like this:

["REQ", "SUB1", { "authors": ["11"], "limit": 500 } ].  // 1
["REQ", "SUB1", { "authors": ["22"], "limit": 2 } ] // 2
["EOSE", "SUB1"] // this could be 1 or 2, since 2 is faster.
["REQ", "SUB1", { "authors": ["33"], "limit": 500 } ] // 3
["EOSE", "SUB1"] // here we don't know which it is, if 1, 2, or 3.
["EOSE", "SUB1"] // now we know all of them have finished
["REQ", "SUB1", { "authors": ["44"], "limit": 500 } ]
["EOSE", "SUB1"] // normal

If this is the desired behavior, we should specify that on NIP-01. If that is the case, I will change my lib to wait for an EOSE/Closed to finish before sending a new REQ.

The option would be to specify that if a new REQ arrives, the relay MUST kill the current process and not reply an EOSE/Closed to the older version.

To me, we need to pick a side. Leaving it undefined is a problem.