At the risk of sounding too academic, one of the distinguishing features of Julia is that it (mostly) retains universally recognized mathematical conventions except in cases where there is absolutely some sort of software concern that precludes this.
Every single person who reads e^A where A is a matrix in any context other than programming recognizes this as a matrix exponential, so if we make this something other than a matrix exponential, we’d better have a damn good reason.
The fact that exp(A) is elementwise in nearly every other widely used programming language oriented towards numerics (Matlab, Python/NumPy, R, Fortran, Scilab, and Julia itself prior to 0.7) is a pretty decent reason.
Now that we have exp.(A), it is pretty reasonable to redefine exp(A) to expm (and deprecate the latter), but it’s important to recognize that there is a tradeoff here.
But that applies to any other function as well, why should exp be different? Instead, it would be nice to have exp do the Right Thing™ based on the type of the input, which is probably the most Julian behavior.
I’m not advocating that it should be different from anything? exp(A) will definitely not be elementwise in 0.7. The question is whether we define it at all. All I’m saying is that there is at least a reasonable argument for leaving it undefined when there are two competing definitions for a function (elementwise in technical programming languages vs matrix exponential in linear algebra). It’s not an overwhelming argument — I’m not opposed to choosing the matrix-exponential definition — but we should at least consider the tradeoff.
I understand your concerns about tradeoff for people coming from other languages, but Julia has the opportunity to do something better, as @ExpandingMan said.
I think the notation e^A also needs to be discussed. In my opinion, both exp(A) and e^A are matrix exponentiation, while e.^A and exp.(A) are element-wise exponentiation. In any case, both e^A and exp(A) should mean exactly the same.