Unfortunately if ‘dissect packages’ is selected making sure that you never do bidirectional criss-crossing is not enough to assure that everything goes well.
Suppose you have a database (package) with two documents B and C and one administrative file A (the administrative file maintains the location of B and C, the index, metadata and so on). Represent this as [A, B, C]
Now suppose you modify B in the source. This changes not only B but also A. So the source becomes [A’, B’,C].
Then you add D to the target. This too is accompanied by a change in A. So the target becomes [A", B,C,D].
Now you do a trial sync. You will find that A’ conflicts with A", that B’ will be transferred from source to target and D from target to source. You let ChronoSync solve all problems by syncing from source to target (once only). Now the source remains [A’,B’,C] and the target becomes [A’,B’,C,D].
Now there is a problem: the target contains a document (D) that is not registered in its administrative file (A’), so it will not be found in searches, it is not available to DEVONThink’s artificial intelligence, you will not find it in the group hierarchy and so on. You may not be aware of that problem if you forgot that you added D, but it still exists.
Furthermore, next time you sync the other way round the source will have the same problem!
This is why, in the previous comment, I emphasized that packages do not exist at the Unix level! At the Unix level a sync utility or sync server cannot know that a DEVONThink database should be treated as a file rather than a folder and so any form of Unix syncing (whether it be Dropbox sync or ChronoSync sync with dissect packages) might easily lead to problems.