I have to admit that I am not entirely getting the "spirit" of the conversation through the stream-of-consciousness design.  What is fundamentally wrong with ublas?  And why not talk about fixing/extending it rather than rewriting it from scratch?

Since I am am not able to post on the boost::developer, as a "representative ublas user", I will contribute for discussion is the following:

• No one wants a new matrix/vector library.  Even if it is "better", there is a fear that it will stay half-finished and unsupported like 99% of those out there.  This has been mentioned on this list, but it seems to be ignored.  Couldn't everyone force their energy on evolving ublas?
  
• I, for one, second the focus on the bindings as a solution to a lot of troubles. Matlab may be great at the arithmetic matrix/vector operations, but it builds horrible habits for more advanced linear algebra (i.e. I never see people never use sparse or structured matrices in matlab.  And I have never seen people use anything but inverses for solving systems)
  
• But it is not all about the bindings... This list and ublas have sometimes underestimated the importance of emulating Fortran/Matlab syntax.  People get very comfortable with Matlab and see Fortran as a much clearer evolution to a "real language" that is designed around matrices and scientific computing.  Since Matlab is the de-facto standard DSL for linear algebra, shouldn't it be the goal of the C++ EDSL?
  
• When I was trying to teach people ublas, everyone was incredibly hung up on the lack of overloading an operator* and nested multiplications.  And if I had to guess, this discussion on the boost::developer list might not have happened if operator* was overloaded....
• Without knowing enough much about the ublas design, I would guess that the overloading of operator* for 2 matrices is possible through crtp/SFINAE.
  
• As for generating default temporaries for nested matrix multiplications, is this at all possible?  I realize that is great to be able to control the temporaries more tightly, but is there no way to have a default (which would enable operator* to work?)
• I will post a starting point for the overloading separately.

-Jesse