Do I read this right? We do padding by the length that does not include the leading 1 bit, but not actually remove the bit from the index before appending the bits to the output?

Example of what it looks like is happening here (assuming get_previous_power_of_2(i) just returns the closest power of 2 at i or lower):

indices = [ # (in binary for example purposes)
0b10001
0b1011
0b110001
]
o = 1
o = 1 0000 # pad
o = 1 0 0001 # add
o =    1 0001 000 # pad
o =    1 0010 011 # add
o =    1 0001 011 00000 # pad
o =    1 0001 100 10001 # add

What I expected:

o = 1
o = 1 0000 # pad
o = 1 0001 # add
o = 1 0001 000 # pad
o = 1 0001 011 # add
o = 1 0001 011 00000 # pad
o = 1 0001 011 10001 # add

Fixed! For inputs (10001, 1011, 110001) the output should indeed be 1 0001 011 10001 now.

Maybe use bit_length(), or at least log2()? And maybe explicitly rounded to an int, if choosing the log function?

Fixed to log2. I was assuming we have log2 explicitly defined elsewhere; if not happy to do bit_length() instead.

Worried about the [int, str] a bit, since they are exclusively (from each other) used based on typ. So e.g. Container with int is invalid. It is likely something to revisit with partials/other uses, but is ok for now.

I think in all cases where we expect to use paths, the path would not be serialized, and it would be explicitly constructed directly as an input to get_generalized_index or similar methods (ie. never saved as a variable). So I think it's fine for that reason.

Yes agree there, but we can maybe make it less error prone. We have others that are unfamiliar with the interface and need to use it as well.