Q:

What happens during Server to server replication if reader access is revoked

I would like to understand what happens in the following Lotus-Domino server to server replication scenario:

Server A has a replica of A database. 
Server B has a replica of the same database. 
Both servers have manager access on the database, including the delete document privilege. 
The replicator process has just replicated A and B and all is in sync. 
The database contains a note that has a reader field where both servers are mentioned. 
On server A the entry for server B is removed from the readers field.
Server A initiates the replication with B.

In this scenario I expect that server A will remove the document from server B. There are variations on the scenario, server C replicating with B, B initiating the replication with A. 
I have an application that is build around this expectation, and it has worked well most of the time. But there are notes that remain on server B and are excluded from the replication process. The OID remains different. There are instances where the DSN is updated on both notes without any result in the replication process.

A:

Actually, I disagree with AndrewB's answer.  In my experience, it should work as per your expectations.  Using readernames fields to control replication has been part of my standard arsenal for 15+ years, and I have found it far more reliable than the alternative of selective replication -- which is evil and should be avoided at all costs, but that's another story!  
It is true that once the readernames field no longer contains the entry for serverB the note itself is invisible to serverB, but the fact that the note has changed is not invisible to the replicator.  The replicator should notice this, determine that serverB no longer has rights to the document, and remove it -- without leaving a stub.
Have you tried clearing the replication history on both sides?  

A:

IBM has created an SPR for this:

Problem Normally, when a server is removed from the reader field of a
  document, after scheduled replication takes place, the document is
  deleted from the server since that server no longer has access to the
  document. In some cases, when a secondary server is removed from the
  reader field of a document residing on a primary server, after
  replication occurs between the two servers, the document is not
  deleted from the secondary server as is expected. Enabling replication
  debug reveals the following error on the source server: "You are not
  authorized to perform that operation". Clearing the replication
  history and initiating replication from both servers does not resolve
  the problem. Upon further investigation, it was determined that the
  document on the secondary server had a higher sequence number which
  implies that it was updated more recently than the document on the
  primary server. Normally, when a document does not contain a reader
  field or if both servers involved in the replication are listed in the
  reader field of both copies of the document, a replication conflict
  will be generated when the document is modified on both servers before
  replication takes place. However, in this particular situation, since
  the secondary server does not have access to the document on the
  primary server, replication fails as is expected and a replication
  conflict is not generated because in order for a conflict document to
  be generated, both servers need to have access to the document.
Resolving the problem
  1.) A short term solution would be to modify the document on the primary server so that its sequence number is higher than document on
  the secondary server. After replication takes place, the changes
  should replicate to the secondary server and the document should be
  deleted from the secondary server as is expected.
  2.) A more permanent solution would be to prevent users and servers from making changes to the document on both servers at around the same
  time. Also, replicating more often should help reduce the chances of
  such a condition from occurring since changes made on one server will
  possibly replicate out before changes are also made on the other
  server. This issue issue is being tracked under SPR MKHS8MLQVD

