Not sure how you got numeric guids here, the Sql backend code actually 
creates non-numeric values here also. Closing, this is not a bug.

You are right, if the suids (the array keys) are not numeric this is 
not an issue.
I was currently testing using the dummy "Sql" Syncml backend included 
in horde, using numerical suids.

Actually, looking at this closer, this doesn't make sense to me. Why 
are the array keys getting "cleared and renumbered"? array_merge 
should not reorder the keys unless they are numeric, which guids are 
not. The tasks and the calendar entries shouldn't have equal guids 
either, so there should be no overwriting.  Or do I misunderstand the 
issue?

If it's of any interests, in my tests i used a Nokia E71

I don't have a nokia device to test/verify with, but the explanation 
sounds reasonable.

in lib/SyncML/Sync.php, function "createSyncOutput", the variables 
$this->_server_adds, $this->_server_replaces and 
$this->_server_deletes contains arrays mapping suids (array keys) to 
cuids (array values), like this:
---
array (
   suid1 => cuid1,
   suid2 => cuid2
);
---
If  $device->handleTasksInCalendar() is true and the current database 
being synced is "calendar", those array will be merged to the 
corrispective add, replace and delete arrays for the "tasks" database.
The merge is made using array_merge, that clears the keys re-numbering 
them; this causes the wrong suids being retrieved from the database. 
Merging the arrays using the += operator solves the issue (if the 
device is reported to handle tasks in calendar, no key collision is 
supposed to be possible)
---
                 $this->_server_adds += $this->_server_task_adds;
                 $this->_server_replaces += $this->_server_replaces;
                 $this->_server_deletes += $this->_server_deletes;
---
---