> 1. (make-condition-type symbol fields) accepts as fields either a
list or vector. I don't remember whether vector as self-evaluating or not in
R7RS. In any case, it is unclear whether it is necessary to accept both
list and vectors. In other words, what does that freedom gives to users?

The original design only used vectors. This is because the R6RS
procedural interface and the SRFI 99 procedural interface used vectors.
I believe I added the ability to send lists in for ease of use, since
other APIs allow for lists.

It is not necessary, and could be changed to one or the other.

 > 2. Anyway, whether fields are passed as vector or list, the returned
accessors are returned as a vector, which slightly more verbose and
cognitively heavy compared to a list, in particular when destructuring
the fourth returned value with `match`.

This goes back to R6RS/SRFI 99 returning vectors. I believe the
rationale is[1] that records are basically vectors (they are a fixed
size and have O(1) access), and R6RS records are really indexed by
integer and not by name. One does not have to take the R6RS/SRFI 99 view
on record types, though.

One is more likely to do vector-like operations on the accessors than
list-like operations. I.e. one is more likely to do random-access
operations than do something like `cdr` or `drop`. So I think vectors
are worth the inconvenience.

-- Peter McGoron

[1]: See this thread https://srfi-email.schemers.org/srfi-99/msg/2773703/