Hi Stefan,

thanks for your interest.
actually I did not want to really change any type system but only follow the taxonomy of uBLAS. 
I took the definitions provided by uBlas docu for matrix and vector concepts and adjusted those for tensors. See http://www.boost.org/doc/libs/1_66_0/libs/numeric/ublas/doc/container_concept.html. A multiarray concept has been already developed in http://www.boost.org/doc/libs/1_63_0/libs/multi_array/doc/reference.html#MultiArray I think the only new concept is the multidimensional iterator. This will be difficult to develop. But we do not need it for first shot of the library. It would just be consistent with the current uBlas version. If I am not wrong even matrix operations provide iterators, see http://www.boost.org/doc/libs/1_66_0/libs/numeric/ublas/doc/matrix_expression.html#41UnaryOperationDescription. Not sure if we need that.
So I only wanted things to be consistent, at least for the proposal.

In short, programming-wise I think:
- tensor template class is a must.
- tensor expression templates, entry wise tensor operations and tensor unfolding are a must.
- iterators are nice to have.
- tensor slices and views are a nice to have.
- in-place tensor contractions are also nice to have.
- efficient in-place tensor contractions are really hard to implement.

We would need to agree on :
what tensor parameter do we want to be compile-time or runtime variable?
do we want the same flexibility as boost::numeric::matrix or boost::numeric::vector?

I have already implemented a tensor library without expression templates (runtime-variable rank, dimensions and even storage format). However almost all of the tensor operations I have described in the proposal are implemented. However, the interface needs to be adjusted really as I did not use expression templates. You can read about the library and concepts in: https://arxiv.org/abs/1711.10912

I would like to start to contribute to the boost community and hopefully try to write a paper about it, similar to the authors of Boost.MultiArray. See https://onlinelibrary.wiley.com/doi/pdf/10.1002/spe.630
I think this might be a good start. Of course in future, I would love to add a full library which will cost more time.

I hope I could answer some of your questions.

Regards,
Cem