I'm sorry for saying this only at the last minute, but I haven't been thinking about arrays for a long time until just the past week.
I think that SRFI 164 needs an array-map function for element-wise processing, to support what APL calls scalar functions. Here's some proposed language:
Specification:
(array-map proc array1 array2 ...) -> list
Applies proc element-wise to the elements of the array arguments and returns a newly allocated array whose elements are the results of the applications. The result has the same shape as the array arguments; it is an error if any two arguments have different shapes. It is also an error if proc cannot accept as many arguments as there are array arguments and return a single value. The dynamic order in which proc is applied to the elements of the arrays is unspecified.
Rationale:
While it is possible to implement this on top of array-ref, it is considerably more efficient, if the arrays are simple, to implement it directly on top of their backing stores. It is an essential primitive for matrix negation, addition, and subtraction as well as for many other purposes, just like map, vector-map, string-map, and various other map functions. This basic version does not support broadcasting of lower-rank arguments to higher-rank ones.
Issue:
When should the result be mutable and when immutable? Do we need two different map procedures, or is there a natural right answer based on the immutability of the array arguments? Some plausible answers: (1) always mutable, (2) always immutable, (3) the same mutability as the first argument, (4) mutable unless all the arguments are immutable, (5) immutable unless all the arguments are mutable, or (6) all arguments and the result are required to have the same mutability.
A similar array-for-each procedure, iterating over the elements of the array arguments in lexicographic order and returning an unspecified value, might also be a Good Thing.