With the “power” of smart rules you are able to move a replicant to the same location as its originating file. After the move only the moved instance is available. The other instance (originating file) is deleted.
@cgrunenberg: Can you tell if an action like this has some negative side effects for the database and might even be a bug or is it handled gracefully and can be used at will?
There is no such thing as the “originating file” in this context – all replicants are identical.
So, you move one replicant to the same group as another? I just tried that (drag & drop and “Move” from the context menu) – that’s not possible. Do you actually have a smart rule that does what you describe?
I used this term because it is in the manual. 
Page 11:
Note: Replicants cannot be created in the same location as the originating file, nor can they be made across databases.
I know that this is not possible manually. I have a smart rule that moves items to the inbox. That’s how I noticed it.
That is true. But once a replicant is created, there’s no difference between them. There’s no priority or special significance or metadata unique to either of the replicants. The only difference is the location.
It’s a fun semantic knot that comes up every once in a while here and I think the devs have tried a few ways to phrase the description of how they work to eliminate confusion. This is my opinion of course but because it’s such a cool trick it will always be a little befuddling at first.
2 Likes
I think it’s because there are few real-life equivalents of the concept of “replicants” to which one could relate. The best I can think of is the investor who is a board member of multiple companies at the same time.
Here˚s another try to put my question: File “a” is in my inbox. I replicate that to another location and rename it to “b”. A smart rule moves “b” back into my inbox. “a” ist deleted, “b” is there.
I know that a manual move would not be possible because replicants can’t exist in the same location. I just wonder if this smart rule behaviour is just a bug and should be avoided. But perhaps this edge case was taken into account by @cgrunenberg and therefore it is by design to delete “a” and keep “b”.
Both instances are now named “b”, replicants are not aliases.
But there is no longer a second instance. I just tested it with an empty database and after the move there is just 1 item in the database …
You can’t have multiple replicants of the same item in the same location. And what would be the point of that anyways?
I don’t want to! I just asked if this might be a bug. The smart rule could refuse the move like it is handled in the GUI. But if it’s OK to “overwrite” with smart rules I’m fine with it.
Considering the replicants are instances of the same item, I would say removing a replicated instance indeed logical.