1. Is there a reason to require bytevectors as the input/output state
representation? There is no guarantee that any bytevector would be a
valid input (it may not be structured properly or may not be of the
correct length). The state should be a datum like in SRFI 27. Ports
should also export some predicate to check that initializing the port
with a datum value is OK (won't result in an exception being raised).
(This will also obviate some issues during serialization, like endianness.)

2. > There is no requirement that the data contained in or read from an
initializer be a state representation extracted with random-port-state:
make-random-port must support initializing a port from arbitrary data.

    I don't understand this sentence.

3. >  What if the state representation for a given library changes
slightly between versions

    If the same equal? argument had defined behavior in a previous
version, and fails to have that in a future version, that is a major API
breakage. I don't that's something that can be treated at the standard
API level. Ideally, an implementation would add another library, or
treat the previous data in a special way, which will depend on specifics.

-- Peter McGoron