Are the error messages important? Are the results wrong?

The messages themselves are mysterious in that they do not arise from TensorRank:

Trace[
 AXA = M12 . PseudoInverse[M12] . M12 // TensorExpand,
 tr_TensorRank :> 
  Check["Success"[HoldForm[tr] -> tr], HoldForm[$Failed@tr]],
 TraceInternal -> True]

Every evaluation is a "Success".

It turns out that the message comes from an internal pattern-check function used in the tensor-expand tool SymbolicTensors`SymbolicTensorsDump`$TensorExpandRules. The check prevents a rule from being applied to a product x*b if x is not a scalar. This is a good thing. I'm not sure why it deserves a message when x is not a scalar. It is possible that TensorExpand does not deal with Hadamard products. (Are there rules/identities? Not my area.) The list of rules is long, but I did not find a rule for dealing with them. I may have missed them.

If there are identities, you may be able to apply them, if TensorExpand[] does not.

Trace[] and relatives trace the steps of evaluation and are documented here: https://reference.wolfram.com/language/ref/Trace.html and the "See Also" section near the bottom of the page.

TraceInternal I've known about for years and years. It's not in the documentation, and I don't know how I learned about it. Maybe an old Usenet group. Setting it to True shows more of the internal steps, which can involve megabytes or even hundred of megabytes of output. Some internal functions are not traceable (for instance, calls to the LAPACK library functions). Some function reveal some of the internal machinations with the setting False (for instance Plot). The normal usage by regular users is to debug their own programs or to understand the evaluation procedure.

How did I find my answer? Not easy to answer. First, I've used Mathematica for over 30 years, and I feel I can predict fairly well what types of things might be happening under the hood, so to speak. Second, I've used Trace a lot, and I'm familiar with the structure of the output and know some tricks. Like Control-Period for moving up the evaluation chain (or double-click and drag). Third, there are some things that are relatively new that help: GeneralUtilities`PrintDefinitions (will print the code of some of the internal functions),Position[] (to search a very large trace output), the Find menu command, and the 3-dot button on messages.

Now, in your case, the 3-dot button on the message will show the stack trace, which contains the offending line of code. Tracing evaluation for that failed, and I kept making my pattern more general and included TraceAbove to figure out how the line was called. I used Find and Control-Period, which led me to the tensor rules. Usually people who do this are befuddled the first time, and they're surprised it takes me only a few minutes. Anyway, this gives the code in which you can find the answer, if you want to play with it:

Trace[
 AXA = M12 . PseudoInverse[M12] . M12 // TensorExpand,
 HoldPattern[If[_, _Message]],
 TraceInternal -> True, TraceAbove -> True]

But don't get your hopes up too much. I tried to describe the core of the problem inmy previous answer. But to elaborate a little, the check keeps from being applied a rule that factors out a scalar from Dot: (x*a).b) -> x*(a.b) is valid when x is a scalar but not if it's a tensor of rank > 0. If you pore over the tensor-expand rules, you may find that there are none that deal with Hadamard products. But I think the error messages do not indicate an error in your code.

But what do you mean? Let's just stick with one example for clarity:

(A*B).C

What do you want that to evaluate to? If I were to do that on paper, well, I'd just write

(A*B).C

To say "the dot is not evaluated" implies that you have in mind some expression that it should be evaluated to. What is that expression?

Okay, I think I understand the context better. I'm wondering why you think "solving it with with explicit arrays would be tough". I don't know that it isn't tough, I'm just wondering if you've actually tried it and determined that to be infeasible.

But as for being stuck on solving for A2 in

A1*A2 == C.PseudoInverse[B]

why can't you just divide?

A2 == C.PseudoInverse[B] / A1

I may be way over my head here, so sorry if I'm missing something. Maybe I still don't understand what kind of workflow you're trying to build.

Okay, I'm sorry for being simplistic. You're wanting to solve things symbolically, but you only are doing this to reduce the computational burden (at least that's what I thought you said). At the end of this whole exercise, you are presumably going to plug in actual data, as in actual numeric matrices. All I'm saying is that if you have this expression

A1 * A2 == Z

that's just a shorthand for a whole system of equations. So, if you have numeric values for A1 and Z, then you can just solve for A2 directly. If A1 has zeros, then you can't get solutions for those entries in your matrix anyway. If you divide, you'll end up with Indeterminate expressions at those locations, but you'll have values everywhere else. Again, maybe it's just my ignorance, but I don't understand how you can get better than that in this case. Or you could do this instead if you like:

Solve[A1 * A2 == Z]

In this formulation, you'll need to have a full representation of A2, but that's not hard.

Or, maybe we can just take a completely different tack. Do you know the mathematical formulas for what you want (as in how to compute the numeric matrices, not just symbolic expressions)? If so, just provide those and we can probably figure out how to turn them into WolframLanguage expressions.

Or, yet another alternative, just solve the whole system with symbolic entries to come up with a formula, and then apply that formula to your data. I would think that would be more computationally intense than just solving numerically, but at least you'd only have to do it once and all future numeric calculations would be easier (I assume).