[NNTP] Article Reinstatement, Was Article Numbers Becoming Invalid (RFC 3977)

Okay, so I *finally* read through all the postings for the thread which =
I started.  Sorry about that!  Now I am happy with the outcome, it =
confirms my understanding of the specification, and all the errata are =
good.  But as far as I can see there is still one more problem ...

Article reinstatement, besides the stated uses of gradual cluster-wide =
synchronisation (which makes perfect sense) poses a small problem for =
many clients using articles as intended, monotonically increasing unique =
per-server references to articles.  If a client should not be aware that =
an article has been removed pending reinstatement, it has no reason to =
suspect that the low watermark will ever decrease.  Even if it wanted =
to, it could not straightforwardly obtain any articles that were added, =
and then removed pending reinstatement, both in the client's absence, =
when they were finally reinstated.

Example: news.test has 5 messages, min=3D1 max=3D5.  Article 1 is =
removed.  Server indicates on group entry to news.test, min=3D2 max=3D5 =
no=3D4.  The client updates its counters to indicate that article 5 was =
the last article seen.  Article 1 is replaced.  Client connects, server =
indicates min=3D1 max=3D5 no=3D5.  How is the client to ensure the =
retrieval of article 1?  The low watermark may certainly indicate its =
presence, but it can hardly assume that an article was reinstated simply =
because on this occasion min=3D1 is the smallest value seen; the article =
numbered 1 may already have been fetched under normal conditions, or the =
heuristic will not work at all if group expiration on criteria other =
than number of articles has occurred, for instance.

Does anybody have any ideas?

Cheers,
Sabahattin