The class that causes the main problem is called TransferManifestNodeFactoryImpl. This is the class that takes a noderef and generates an object that is later rendered into XML for transferral. It implements the basic interface TransferManifestNodeFactory and, as with most things, can be replaced with an alternative implementation via Spring if desired.
If you'd like to do that, then the area of logic that you should consider changing is in the first 20 lines or so of the createTransferManifestNode method in the out-of-the-box implementation. This is trying to work out whether it should be creating a TransferManifestDeletedNode object or a TransferManifestNormalNode object.
I suggest that you alter this logic in a custom implementation such that if it is given a noderef that is in the archive store then it assumes immediately that it should create a TransferManifestDeletedNode object. Otherwise it follows the same logic as the current implementation.
If that change was made then you could force the removal of a node on the receiving side by "faking" an archive store noderef based on the actual noderef. That is to say that if you want to force the removal of the node "workspace://SpacesStore/8d02b691-ecab-49b6-98d3-e7dd991ddd54" on the destination then you would actually put this noderef into the transfer definition: "archive://SpacesStore/8d02b691-ecab-49b6-98d3-e7dd991ddd54".
Does that make any sense? Come back to me if not, and I'll have another stab at explaining it.
Just for information, the approach that I've taken to resolving this in the 4.0 stream is different to what I've described above. I have added an additional set of noderefs to the TransferDefinition class that is used to hold nodes that are to be removed from the target repo. The TransferManifestNodeFactory interface now allows a flag to be set that indicates that the caller wants to force a removal of the specified node. I think this is neater, as it removes the need to rely on the archive noderef as an indicator.
