I have upgraded openldap to latest stable version (2.3.38) and used Berkeley DB version 4.5.20. The problem remains. I realize my analisys wasn't correct since, as Howard Chu pointed out, the CSN contains both a timestamp and a counter. So the entryCSN:s are unique.
But, the problem remains and I have no idea why this happens. I somehow still suspect that the problem still is in the initial phase of the sync operation (refresh stage). It might be that, some of the not-yet committed modifications don't make it into the result set in the search operation. Later after another entry is added, the "lost" entries are never to be synced over.
I will test some more and try to provide more information. I have a test program that generates this problem but it is a little cumbersome. I will try to slim it down and use more common schema elements before posting it.
Regards
/Stelios