That has solved the problem. I have a long list of rules. Would it be better to always use delayed evaluation? This one is only that rule that seems to be problematic, but there might be other undiscovered gotchas hidden in the list.
Eric
ETA There were other problems. The delayed evaluation worked when applied to the complete list.
The delayed rule is usually safer than the immediate rule, just like it is usually recommended to define function the delayed way f[x_]:= instead of the immediate way f[x_]=. There are some situation when the two rules behave in a dramatically different way, for example x:>RandomReal[] and x->RandomReal[], and you have to be careful.
The disadvantage of Replace is that you can easily make complicated riddles like this one. Most experienced programmers don’t solve these riddles - they just avoid them completely.
As convention, people often add a “$” to the front of variables that are “internal”. So let’s try that:
a = v;
a b /. $a_ $b_ -> $a + $b
This works. There’s no confusion about what the “a” on the right hand side of the arrow means.
In general you want to avoid undescriptive variable names. That also avoids this problem.
Now to explain what happens.
a = v;
a b /. a_ b_ → a + b
First a is replaced by v per its definition. So we effectively have:
v b /. a_ b_ -> v + b
"Then the product is reordered alphabetically because “v b” is equal to “b v”. So now we have “b v”.
Sorry, when I posted it the first time, I got a message that some further classification was needed, so I added another one and posted. But it looks like the first one when through anyway.