How odd. Truncate table takes out an exclusive lock because it is writing. This blocks and is blocked by shared (read) locks of the sort that create index takes out. Whichever gets there first will run to completion and then the other will start running. It is actually impossible to have both running simultaneously - one will always block the other.
Just checking - you've run dbcc checktable and dbcc tablealloc on your table and it came up clean? Did you physically recreate the table (select into a new table, drop old table, rename new table)?
If the issue really is truncate table and create index running simultaneously, you could force the correct locking sequence by using the "lock table" command before you run the create index. You need to be in a transaction to do this. That guarantees create index couldn't possibly run while truncate table is running... although that's how's it's supposed to be normally. But the Sybase engineer must've had a reason for saying what they did. :)
Try the physical rebuild of the table (if you haven't already), and then using a lock table statement before the create index.
