> The name 'binary32' in bytevector-binary32-ref etc. assumes general
consensus that it refers to IEEE754 terms.  This may not be an issue,
as we have no conflicting usage other than referring to flonum
formats.

It could be renamed to bytevector-ieee-binary32-ref, but that's quite
long, and I think no confusion arises if they are simply referred to as
binary32.

 > If we won't have such procedure, or we'll instead have
(bytevector->flonum-list bytevector endianness format [start [end]]),
where format is 'binary32, 'decimal64 etc., then we can coexist with
bytevector-binary32-ref.

IEEE-754 2019 defines how to extend the binaryN and decimalN formats to
N beyond the standard number of bits. The hypothetical procedure would
probably look like

      (bytevector-binaryN-ref bytevector bv k endianness size)

      Reads a binaryN number, where N = size*32. [other stuff here]...

      (bytevector-binaryN-set! bytevector bv k x endianness size)
      (bytevector-decimalN-ref bytevector bv k endianness size)
      (bytevector-decimalN-set! bytevector bv k x endianness size)
      (bytevector-binaryN->list ...)
      (bytevector-decimalN->list ...)

I am not aware of people interchanging binary512, etc, numbers, so the
procedure is probably not necessary. People with such needs may use a
format that deviates from IEEE, because their needs are so specific
(like those who make 8-bit floats).

-- Peter McGoron