Finally I managed to read your code, so I can give you the full feedback. I have an overall idea of how your proposal can be changed, but I want to respond to your comments individually first.
- it is true that several functions that one might expect to be in the interface of a math object only conditionally make sense if the underlying container supports dynamic memory allocation, but this can be applied to any object, such as an STL container. There are circumstances that lead a user to use a static std::list or std::vector, but this does not justify the creation of two identical containers that differ only in static or dynamic memory management. If this were done, the STL library would be much bloated, making the existence of the allocators partly useless: since the allocator is used to abstract the memory management (or rather, it is a handle to the memory), you can implement an allocator that is essentially a handle to a static array. In this way, although it is not very elegant, it is possible to create a custom fixed_vector or a fixed_list by passing, respectively, a static allocator to a std::vector or a std::list. It is up to the user to avoid calling member functions that can lead to memory resizing, such as reserve(), otherwise a std::bad_alloc is thrown, as if a simple dynamic allocation failed.
- if you want to adopt a container adapter interface, as already present in all container adapters, you create two overloads for the constructors, one without an allocator and the other with an allocator (if the std::uses_allocator type trait is true).
- although already-existing containers do not support efficient multidimensional resizing, it is still possible for the user to implement a custom container. It depends on what the user thinks.
But your comment "existing containers don't support efficient multidimensional resizing" is precisely the key point: over the guarantee of a complete interface for performing linear algebra operations, does the matrix container offer advantages in terms of flexibility and performance?
In my opinion, creating a matrix container, whose implementation takes the best features between std::valarray and mdarray would be the best. Without introducing new containers or container adapters, the matrix container could fill some of std::valarray's shortcomings by providing an interface that allows the user to perform easily simple and complex linear algebra operations on N-dimensional arrays.
If that is okay, you can present a draft of the matrix container, especially highlighting the benefits of linear algebra operations and memory management.