That would be very strange.
SRFIs 4 and 160 do not in fact guarantee compact storage either. More practically, it's a fallback: if your Scheme does not have specialized inexact complex vectors, you can simulate them with ordinary vectors.
I didn't try to specify a way to create new gvector types because the I think
natural way to do it is to define a new "interface type" that "extends" gvector.
That is the natural way to in most object-oriented platforms (including Java and Kawa),
but some people (including seemingly you) are leery of inheritance, at least in
terms of how Scheme should be designed.
I have no personal objections to interface types. But Scheme has historically been monomorphic, and I think the amount of political work required to get either classes or interfaces widely used and standardized is too big to succeed. Therefore I have been leaning toward reified type classes like SRFI 128 comparators on the one hand, and predicate-based generic functions on the other, which don't require significant retrofitting into either monomorphic or polymorphic Schemes.
However, there is nothing preventing adding support for SRFI 122 storage classes
to SRFI 164. For example one could add the procedure
(make-specialized-array SHAPE STORAGE-CLASS)
to SRFI 164 fairly easily, I'm pretty sure.
Indeed. Would you consider a revised SRFI or small extension incorporating storage classes (by reference, no need to copy them) and this procedure?