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!.
Okay will do!
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.
I can't confirm this, I've tried calling radix-copy-path seperately and it seems to function as expected. I think I tracked down the actual error to the way I'm calculating the remainding space in the current vector in final-vector-remainder. So what was happending was that when the (radix-length radix-struct-write) equaled 32 the function would take the modulo 32 of this which is 0 and subtract it from 32 resulting in it saying there was 32 spaces left rather than zero. The following change to radix-append seems to have resolved things:
(define final-vector-remainder
(- 31 (modulo (- (radix-length radix-struct-write) 1) 32)))
Thanks as always for the tips anon. I think I'll start the relaxed rewrite this afternoon, hopefully it goes well.