I must say that I am not convinced that something like
>> plain C = A * b;
is easier to understand for a beginner than
>> auto C = (A*B).eval();
. It introduces a new type and it also rather looks like a keyword in that context (particularly since all Eigen types start with upper-case letters), and it might add more complexity/confusion.. Maybe it's just the name "plain" that is bad, perhaps we could find something better, along the likes of "PlainObject" or something like that, but that's also not too obvious yet to a beginner, and I don't have a good idea for that name.
I do quite like the idea of the "deduction guides" of
Matrix M = ...;
SparseMatrix S = ...;
Array A = ...;
though, so perhaps that's what you're looking for to eliminate the need for .eval() for beginners.
And then for generic code you could still have "PlainObject" or something like that, but just don't teach that to beginners in the documentation.
>> we could then decide if, e.g., Eigen 4 supports C++11 and someC++14/17/20 features.
Just my two cents, might be a bit off-topic here, but in my opinion it would be a real back-step if the "hypothetical" Eigen 4 was stuck on C++11. I would very strongly argue to at least make the step to full C++14 and potentially C++17 (I think there was some memory-alignment keywords in either C++14 or 17 which would make EIGEN_MAKE_ALIGNED_OPERATOR_NEW unnecessary and that would be a *really* big win imho).
I would actually love to see Eigen 3 moving to C++14... ;-)