This page is about problems pertaining to synchronization itself, not specific implementation problems. In addition to this list, there is also a blog article which explains how synchronization works and what pitfalls exist. Recommended reading, if you have the time.
For information on implementation or interoperability problems, see the Wiki pages about specific platforms or peers and the blog articles which announce specific SyncEvolution release.
If two clients make changes to the same item, the first one to synchronize will copy its changes to the server. The second one then runs into a conflict when it tries to push its own changes into the server.
The SyncML server now has to decide how to proceed. Some decide to preserve both conflicting items, leading to duplicates which have to be merged manually later. Other servers merge automatically and throw away conflicting data based on heuristics; this may remove valid data. The client has no control over the method chosen by the server.
Merging items on the server is difficult because the SyncML protocol does not specify which parts of a conflicting item were updated. In general a server can only make more or less educated guesses which might lead to data loss. It is better to avoid this situation in the first place by synchronizing before making changes.
Removing a field
Removing a field, and then synchronizing with a Funambol server, will not remove that field on the server. The server will preserve the old value instead. Other servers might do the same.
This is necessary because a SyncML server cannot distinguish between removed fields and fields that a client does not store. To avoid losing data, when copying back items from a less capable client, the server preserves missing fields, even in a situation where the field was intentionally removed on the client.
The workaround for this conceptual problem is to never clean (= remove) a field. Better to fill it, for example with a single space.
Changing the type of, for example, a phone number
Changing the type of, for example, a phone number might not be detected by a SyncML server as changing the type, but rather as adding a new number. Because removing fields does not work, the server will keep the number with the old type.