>>Is the temp table local, or on a network share? For the following I'll assume local.
>Single machine, local drive, sys(2023) and sys(3) are heavily used to name temp files instead of cursors.

SYS( 3 ) may return non-unique values if called in rapid succession on fast computers. It's better to use SYS( 2015 ) instead.

>>Do you have to use PACK? SET DELETED ON will ignore deleted rows automatically, including in SELECT - SQL. If you have DELETED set OFF and just need read-only access to undeleted rows you could SELECT ... WHERE NOT DELETED() INTO CURSOR NewOne NOFILTER for further operations. I haven't needed to use PACK for many years except in periodic (monthly/semiannual) database maintenance procedures.
>See comment above about archaeology. It's a temp table to hold line items on a transaction. The PACK and later use of the table is so multiple transactions can be entered without closing/reopening the screen. But that's not a complete caveat - the error often isn't seen until 5-10 transactions are entered, but it's also been seen on the very first.

That opens other possibilities. You may already know that bad things happen if you have, say, a form grid fed by a table (temp or otherwise) and you PACK that table. I don't know if it happens with other controls as well.

Do you have any ON KEY LABELs in effect? On a few occasions I've seen problems where very fast/skilled users blast through data entry, and then save with one hotkey and hit another hotkey to open a new transaction before the first one has been saved.

Is there an antivirus program in effect? If so it should be configured so its real-time scanner does not scan your data and temp files folders.

Another faint possibility would be to check the write cache status of the disk (Device Manager...Disk drives...right-click on the device...Properties...Policies tab. If the write cache is enabled, you could try disabling it. This will reduce system performance somewhat but is actually safer if it's a desktop computer without a UPS.