I've been thinking about how array broadcasting would interact with
other array operations, especially currying and permuting axes.  More
generally, understanding program behavior in the presence of mutation
has been difficult for me.

Combining broadcasting and mutation leads to more problems, as the
mapping from multi-indices in the domain of the array to integer indexer
results is not one-to-one: changing one element could change the value
of an entire slice, for example

So one might think of allowing broadcasting only for "immutable" arrays.

But with array-freeze!, one could curry a mutable specialized array,
extract a (mutable) slice, and then make the original array "immutable"
with array-freeze!.  But something could still hold a mutable slice of
that array, and could screw around with entries of this now "immutable"
array.

So ...

While array-freeze! might be a way to do a necessary thing for library
implementers, I think it would be better if the mutability of an array
could not be changed by a user of the library after the array is created.

And that array-broadcast should be applied only to arrays that are (now)
perpetually immutable.

Because one broadcasts from an argument array with relatively few
elements to a result array with relatively many elements (that's the
entire point of broadcasting, after all), it would have a relatively
small cost to copy the argument array if necessary to an immutable array
with the same elements and broadcasting the copied argument array.

Brad