Hello Michael, I think you're correct that the variables are being (reverse) sorted. Variables[] returns a sorted list, but it doesn't show up in Trace of the OP's code. Algebraic solvers generally need a consistent ordering of the variables (see, for example, GroebnerBasis[]), but that's not really needed for linear systems. Since Solve[] is a general solver, maybe it shouldn't be surprising to see it order the variables; it's not an expensive operation.

You ask about slots. I assume you mean something like a Function Slot[]. While one could adopt this point of view, I don't think that's how it works. I'm accustomed to variables being sorting by their symbol names.

It's also possible for variables to be sorted by order of appearance, but the Trace shows that's not how it's done.

Try

Trace[
 Solve[h1 == h2],
 _Internal`TryLinearSolve,
 TraceInternal -> True]

to see what actually happens. However, I didn't think including such internal evidence worth showing in the answer. (You won't see the actual matrices, so there's some guesswork still involved; however, one sees the order of the variables is as I gave above.)

I don't know why I bothered to answer, I could have just waited ten minutes and saved myself the effort.

I guess I can clarify one thing. NSolve and Solve invoke a common linear solver, and it uses Gaussian elimination with partial pivoting. Which is not always enough to deal with an overdetermined linear system. Maybe NSolve should try harder, but then we get into a gray area where it needs some heuristic to say whether a system is or is not solvable. Not that this isn't already manifest. For example, we take the non-solved case, add a trivial nonlinear equation, and retry.

NSolve[h1 - h2 == 0, {s, r}]
NSolve[h1 - h2 == 0 && x^2 == 0, {s, r, x}]

(* Out[70]= {}

Out[71]= {{s -> 111.111, r -> 110.345, x -> 0.}, {s -> 111.111, 
  r -> 110.345, x -> 0.}} *)

Honk???

Okay, what happens is the special case linear solver is now taken out of the picture. The polynomial NSolve uses whatever heuristics to handle its input, possibly including raised precision, an effort to assess when a coefficient has vanished, or when an approximation to a solution is "good enough to regard as valid".

I actually saved my text before hitting "Publish" just to be safe. It did not occur to me that I could have lost a partial response due to an earlier log-out. Very annoying, when that happens.My apologies, and thank you for persevering and rewriting a detailed answer.

This is indeed very strange. In order to rules out any whitespace character stuff, I have rearranged the code in a way, that it definitely uses the same arguments.

mat1 = {{60, -100, 50}, {59.5, -100, 50}};
mat2 = {{0.18125, 1.45, -0.3625}, {0.1845, 1.44, -0.36}};
vec = {r, s};

eq1 = Thread[{h1, h2} = mat1 + vec*mat2]
Solve[h1 == h2]

RowReduce::luc: Result for RowReduce of badly conditioned matrix {{-0.1845,0.18125,0.5},{-1.44,1.45,0.},{0.36,-0.3625,0.}} may contain significant numerical errors.

NSolve[h1 == h2]

{{r -> 110.345, s -> 111.111}}

eq2 = Thread[{h1, h2} = mat1 + Reverse[vec]*mat2]

Solve[h1 == h2]

{{r -> 111.111, s -> 110.345}}

NSolve[h1 == h2]

{} So for eq1 Solve reports an error and does not find a solution, but Nsolve does. For eq2 Solve gives the solution, but NSolve does not find a solution but also gives non error message