I would like to gauge the interest of the community in a library that can serve 1) as a complement to Boost.MultiArray and 2) as an alternative to Boost.MultiArray.
Caveat, I've taken only the briefest of glances at what's in the sandbox...
For the first type of use, an example of the candidate library's capabilities is that it makes available a special iterator "it" that allows to browse all the elements of a MultiArray "m". This special iterator has an it.indices() members that returns a "list" Collection of indices (i.e. an IndexList) such that "m(list)" and "*it" are the same elements. This can be useful for functions whose effect on an element of "m" depends on where this element is situated in "m".
Does the functionality work atop the MultiArray concept or atop boost::multi_array and boost::multi_array_ref? One can linearly walk the contents of the latter using iterators foo.data() and foo.data() + foo.dimensionality. I think only the MultiArray concept would need further capabilities for a linear walk independent of the dimensionality (as .data() isn't part of the concept). A "position-dependent" behavior can be achieved (atop multi_array and multi_array_ref) by taking the distance between foo.data() and the current iterator and then playing some games with foo.strides() or std::distance(). I believe the same can be achieved atop the pure MultiArray concept using foo.origin(). No need to extend the concept (though the required couple of lines would be frustratingly lengthy). Personally, I've found that writing three overrides of most methods is sufficient to take advantage of the contiguous storage guaranteed by boost::multi_array and boost::multi_array_ref while allowing the general MultiArray cases to work. Aside from runtime dimension selection, what does 'box' add beyond the current extent_gen-based capabilities. (Compile-time) dimension-independent code can be written by templating on the MultiArray NumDims parameter (http://agentzlerich.blogspot.com/2010/01/providing-fill-and-foreach-algorith... is an example). Runtime-decisions about the dimensionality of a MultiArray definitely are interesting but I'm unimaginative and can't think of the use case...
The second way to use the candidate library is as an alternative to Boost.MultiArray of dynamically chosen (execution time) dimensionality. Moreover, the elements do not necessarily need to be arranged in a multi-dimensional "box", as is the case in a MultiArray. For example, a "simplex" organization of the elements is already implemented.
I'm afraid I can't begin to speak intelligently about the simplex organization... I don't think I'm your target audience so take all of this with a grain of salt. I very much appreciate your attempts to further improve the MultiArray concept as I use it heavily in my own work. Also, just cause I find it interesting, ndarray is a fairly cool alternative (https://code.google.com/p/ndarray/). - Rhys