Ran into this again, 5yrs later, and stumbled across my own post. I believe I've got a handle on what's happening here, and thought I could update this in case anyone else struggles with the same issue.

This happens with a join filter. My posts from 2011 weren't really accurate about what the cause/fix was. But changing partition_options to 1 instead of 0 buries the issue slightly.

The problem is caused by a child article being joined to a parent, when that parent depends on the child - this is an issue of processing order in my case. So for example, if you have a "Customer" record that is joined to a "CustomerLocation" record to determine the subscription partition. So replication evaluates "CustomerLocation" records for each partition and will join the "Customer" to those.

But in most scenarios like this, a FK will be placed on CustomerLocation that references Customer.Id. When the merge agent uploads changes it follow the FK dependencies and tries to upload "Customer" before it uploads "CustomerLocation". This is where the problem is caused because that "Customer" record is out-of-partition since the "CustomerLocation" record hasn't been uploaded yet. Even though the "CustomerLocation" is uploaded immediately after, the publisher determines "Customer" to be out of partition, and triggers a delete at the subscriber. The very next sync when all of the data is there to evaluate, the "Customer" record is added right back. This causes the child record to disappear temporarily.

My original post suggested changing partition_options to 1 to fix the problem, but all that does is raise conflicts in the publisher that are resolved at the next sync. So for one sync you end up with "Subscriber has modified a record that is out of partition when partition_options is set to disallow" or something like that, and the next sync that conflict is resolved. This prevents the temporary delete pending conflict resolution, but it still sucks for a solution.

I'd read in BOL that using NOT FOR REPLICATION on a constraint excludes it from the process that determines partition_order based on constraints, and it should fall through to using JOIN filters to determine processing order. But that doesn't appear to be true in my tests. Even though all the constraints are NOT FOR REPLICATION, the system would still continue to upload changes to "Customer" before "CustomerLocation" even though "CustomerLocation" was the parent in the join filter.

To fix this I've had to manually set processing_order on the "Customer" article to merge after "CustomerLocation", allowing the parent to be uploaded first. Since the FK is NOT FOR REPLICATION, it's allowed to merge in that order.