I'm curious what you thing of this
For a project that is not an externally imposed assignment you should work on whichever aspect holds your interest, provided that you do not advertise a project with outstanding issues as bug free to others.
it would make it both more difficult to reason about the performance of the radix tree, and in certain situations even reduce performance so I don't know if it's worth it or not.
If one class of operations loses a small constant factor while another class of operations gains an order of growth improvement, the change is probably worth it. Having said that, you have an outstanding double lookup issue in the append operation since >>16 so performance issues seem to receive a rather mercurial weight.
I decided this was a bit verbose despite having the nice quality of being able to change out the representation and scrapped it. Was this a bad choice?
As a matter of principle, replacing an abstraction layer and inlining a particular implementation is indeed a bad choice. You might do that in a C accelerator module only after profiling shows that your abstraction layer specifically constitutes a performance bottleneck.
I still can't believe you took this much time to correct my work
I could only allocate a portion of my leisure time to this, which is why it took 13 days. It was still fast enough that there are several explained but still unresolved organization, efficiency and correctness issues.