I have been concerned about the
"bitvector<->bytevector" procedures, which currently only use
big-endian order according to the document.
Ah. This is more difficult. When packing (implicitly big-endian) bitvectors into bytevectors, it is not so clear where the padding bits go. Strict reversal would put them in byte 0, but the last byte would also be a plausible place.