My issue is not with the matrix-multiplication operator—I'm a mathematician before I'm a programmer, and so am all for it—but with the vector-to-matrix promotions: why not just consistently promote vectors to columns (or rows, if BDFL swings that way)? This would achieve almost the same effect as promoting to rows or columns as needed, and would avoid the non-associativity problem that the PEP mentions.
This PEP seems to imply that the cost would be a profusion of superfluous `newaxis`s, but I can't see that: it seems to me that you would need only to remember which kind of promotion works by default, and sprinkle in a `.T` whenever you need the other kind. (Anyone who's uncomfortable with lots of `.T`s in matrix-crunching code is not, I submit, someone who writes or reads lots of matrix-crunching code.)
This PEP seems to imply that the cost would be a profusion of superfluous `newaxis`s, but I can't see that: it seems to me that you would need only to remember which kind of promotion works by default, and sprinkle in a `.T` whenever you need the other kind. (Anyone who's uncomfortable with lots of `.T`s in matrix-crunching code is not, I submit, someone who writes or reads lots of matrix-crunching code.)