I just noticed that naive-append-vector! may only be called with a 32-aligned write-position, because it never increases the height of the write-radix on the else branch of the cond. This is fine since it's an internal function and its callers follow this restriction, but this should be stated explicitly. It should also be stated for copy-append! which inherits this restriction from naive-append-vector!.
In the same way, radix-copy-path may only be called with a position that is not 32-aligned at the end of the radix, and radix-set respects this. This is also fine because radix-copy-path is an intternal function, but this restriction should also be stated explicitly. If the position did not respect this, radix-copy-path would malfunction. For example, when called with position 32 on a radix of size 32 and height 1, radix-copy-path will completely ignore the high bit and act exactly as for position 0, including the operation call. When called with position 64 on a radix of size 64 and height 2, radix-copy-path will access the uninitialized third element of the root vector, and pass this to vector-copy.
The problems start in radix-append which does not follow the radix-copy-path condition. It calls radix-copy-path with (radix-length radix-struct-write) even when it is 32-aligned, which can already trigger the problems pointed out above. To make matters worse, the final-vector-remainder computation yields 32 rather than 0 for a 32-aligned length, so the lambda will attempt to use its potentially bogus vector and position arguments for an actual copy. Therefore radix-append looks quite broken from here and needs both these issues fixed.
Can you confirm this chain of reasoning from your end?