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.
From >>20
To make matters worse, the final-vector-remainder computation yields 32 rather than 0 for a 32-aligned length
I can't confirm this, I've tried calling radix-copy-path seperately and it seems to function as expected.
We can very easily resolve which one of us is right. Make a new radix of 64 elements. Append any other radix to it with the radix-append you posted. According to >>20 this will call vector-copy on the uninitialized third element of the root vector. In Guile this is immediately an error:
guile> (vector-copy (vector-ref (make-vector 32) 2))
Backtrace:
In standard input:
3: 0* [vector-copy {#<unspecified>}]
standard input:3:1: In procedure vector-copy in expression (vector-copy (vector-ref # 2)):
standard input:3:1: Wrong type (expecting array): #<unspecified>
ABORT: (wrong-type-arg)
guile>It would be very surprising if your Scheme variant was able to successfully call vector-copy on the default value that (make-vector 32) uses for the elements.
As stated in >>20 final-vector-remainder was merely one issue in radix-append. The other is the unconditional call to radix-copy-path.