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.The reason the documents are left/not updated on server B is that removal of the server B from reader field on the document makes it invisible to the server hence it has no idea that it has changed, or been deleted.The reason that the deletion on server A was picked up by server B is that deletion converts the document into a deletion stub which is little more than the UNID so readers field also go making the deletion 'visible' to server B.
In this scenario I expect that server A will remove the document from server B.
If not, then look for an entry for a group in the Domino Directory that you are a member of, or for a wildcard entry for your organization (the stuff that follows the / in your full Notes user name).
If none of those are there, then you're covered by the -Default- entry.
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.
Have you tried clearing the replication history on both sides?