The replay jumped to 0x1000000003, a CALL record's header: a JUMP's target had been overwritten by the next recording. Tears of the Kingdom gives each model's prerecorded lists fixed slots of the size a recording of that list measured with GetCommandMemoryUsed, slot k at base + size × k, and passes AddCommandMemory max(size, 512) (main+0xbb120; its memory callback is empty). The host kept 24 bytes free after every record for "a JUMP or an END", so a 496-byte list's END went to a host segment and the 16-byte JUMP at 488 reached 8 bytes into the next slot, whose first record landed on the JUMP's target.
The host now keeps 16 bytes (one JUMP) after every record but the END, lets the END take a segment's last bytes, and links only recordings that have records. Every other record is at least 16 bytes, so a JUMP only stands where a record was to go. Lists that fit their slot exactly no longer go to host segments either (the 504-byte lists Tears of the Kingdom records at load did). t_nvn "slotted lists" records lists of 64 to 1064 bytes into such slots: on the old recorder the 496-byte one broke.
seedds
0b3c7b1200