> (Marc) This can be an obstacle for many Schemes. [...]
> In your approach, there is one more pointer indirection,
> making all vector code slower.

Right.  Thank you for explicating that.  Indeed, if resizable vectors are
rarely used, then it seems better to make vectors unresizable by default
and avoid that extra indirection.

> (John) Which is it?  It could use `raise-continuable` [...]
> (Marc) If an exception is raised whenever the vector has to [...]
> (John) As I said, I don't think this idea is particularly meritorious.

Sorry for the vague language.  The intention was to always try to
reallocate when it no longer fits, and to signal a (non-continuable) error
only when such reallocation fails.

> (John) [...] whether the capacity can be set to be
> smaller than the current size.

No (as John expected), unless the vector is truncated first (as Shiro wrote).
`siz <= cap` is an invariant of `Vec`; I should have distinguished between
"shrinking" (reducing `cap`, with reallocation) and
"truncating" (reducing `siz`, without reallocation).

> (Shiro) It isn't necessarily backward-compatible. [...] threads [...]

Right.  I have not considered threads, mutations, and their immiscibility.
Thank you for sharing your experience; I shall look for other ways to
exploit parallelism with fewer difficulties before I resort to threads.

---

After reading everyone's replies, I am now inclined to make my vectors
fixed-length.  Thank you for the insights, Marc, John, & Shiro.

Best regards,

Erik