Yes. Romlog attached (a470 102c) (edit: date is wrong, of course).
Thanks. That's deep in the Canon PTP code, which suggests it could be an actual PTP problem, rather than say, running out of memory or some other unrelated CHDK issue.
My theory is that one of the Canon libraries had a bug that was relatively quickly fixed and only affected a few models.
Or chdkptp is doing something not quite correct that other versions tolerate. There are some weird rules about sending a zero-length packets when the data length is an exact multiple of the max packet size.
Looking for ways to debug this, I was reminded there appears to be a separate logging system connected to PTP, which
maybe writes to "A/BulkTrns.Log"
The logging function is FF9F7AF0 on d10 (sub_FFD9A06C on your a470)
I
haven't yet figured out how to enable it. figured it out while writing this post 
It appears to be set up in sub_FFD9A268 based on a call to FF9FA8F8
This seems to be checking some kind of system with named values, but "PtpBulkLogFlag" is only mentioned in that one place, so it's not clear how to set it. Maybe it's compile time in Canon code. Other names used by the same system (PlatformWrapper.c apparently) are referenced in other places, e.g "PTPConfig.SupportedSlideShow", "PTPConfig.VenderExtensionVerrsion", "PTP GetDeviceInfo Configuration"
There appears to be 3 functions associated with this system:
A set / register function sub_FF9FA7D0 ("name",value)
Value seems to be a pointer or arbitrary constant
A clear / unset function sub_FF9FA85 ("name")
and the above mentioned get function
status = sub_FF9FA8F8("name",*value)
which returns 0 if value is present, or has bit 1 set if not. The original value saved is returned in *value.
The name, value pairs are stored sequentially in memory, starting at 0x785A4 on d10.
Based on the code that checks "PtpBulkLogFlag" the value doesn't matter, as long as it's not 0.
Putting this all together, I made a Lua script that enables the bulk log flag. This appears to only take effect on next physical USB connection (i.e. USB bit being set) and isn't flushed until disconnection. The log is appended between session. The function pointer values are obviously camera specific, but if they turn out to be useful, they should be easy to add to the sigfinders.
In the failed case, the log looks like this
00024920: Op.[0x1002], P1[0x00000001]
00024930: Res.Comp
00024930: Op.[0x1001]
00024930: SendData,Len=385
00024930: Res.Comp
00024930: Op.[0x9999], P1[0x00000000]
00024940: Res.Comp
00035250: Op.[0x9999], P1[0x0000000b]
00035250: ReceiveData,Len=9204
00035250: WaitNullPacket fNullEnd = 1, Total=9216, Current=512, SendLen=87
00048970: DoTransactionCanceled()
Op 0x9999 P1 = 0xb is PTP_CHDK_WriteScriptMsg