>> Would you like more opinions or help with a specific part of it before
>> finalization?
>
> I'd like to feel that I haven't wasted my time.
> That means people reading the specification carefully, giving
> feedback (both on the general approach/philosophy/style and on
> specific functions), and perhaps trying out the Kawa implementation.
>
> It would be great if either an implementor said "this is neat, I'd like
> to add this to my implementation", or a user said "this is neat,
> I'd like to use this either in Kawa or some other implementation".

 From the SRFI 164 list archives, I notice you had concern with lack of
feedback already in Nov/Dec last year. That sucks. It's no fun to write
in an echo chamber. For my part, I regret that this is too little too
late but arrays are such a complex topic that I'm not qualified to offer
useful advice without going into research mode for a couple of weeks.
Your API seems very nice, and I especially like that it has a reshape
procedure which I know from some experience in R/Octave is useful.

The performance and interoperability implications of any array API are
quite complex because the most prominent use of arrays now is machine
learning and other statistical work on huge datasets. That brings
concerns like sparse arrays, float representations, GPU acceleration,
interoperation between things like R, Matlab, TensorFlow, Torch, BLAS
and Clojure's core.matrix. For ML/stats applications, Scheme would
ideally re-use a highly optimized array representation and routines from
one of these industry-standard frameworks. I would hesitate to comment
on how to take all this into account since I'm not well versed in it.