I was pointed to a tiny package for this written by Roman Maeder: Automatic Threading of Equations. Quoting the description:

Automatic Threading of Equations

this little utility was originally developer for DMUG, the German Mathematica User Group (http://www.mathematica.ch/). It answers a frequently asked question about the manipulation of equations. Mathematica does not "thread" arithmetic and other functions over equations, so the following naive approach to solving equations by rearranging terms does not work:

In[1]:= 1 + x == 2

In[2]:= %-1

Out[2]= -1 + (1 + x == 2)

To make this work, the symbol Equal (the head of an equation) should behave like List with respect to listable functions. Just as {a,b}+1 turns into {a+1, b+1}, one may want (a==b)+1 to turn into a+1 == b+1. This can be achieved explicitly with Thread:

In[3]:= Thread[(a==b) + 1, Equal]

Out[3]= 1 + a == 1 + b

The automatic transformation of f[a, b, c, ...] into Thread[f[a, b, c, ...]] should happen whenever f has the attribute Listable and at least one of the arguments a, b, ... has head Equal. This definition is essentially what is needed:

Equal/: lhs:f_Symbol?listableQ[___, _Equal, ___] :=
        Thread[ Unevaluated[lhs], Equal ]

listableQ[f_] := MemberQ[Attributes[f], Listable]

The use of "Unevaluated" prevents an infinite recursion. Together with the necessary framework, the definition is in the little package EqualThread.m.

Now, you can solve equation as you did in school:

read the package:

In[1]:= Needs["EqualThread`"]

the equation, to be solved for x:

In[7]:= a == b Log[2 x]

divide by b:

In[8]:= %/b
    a
Out[8]= - == Log[2 x]
    b

exponentiate:

In[9]:= Exp[%]

     a/b
Out[9]= E    == 2 x

divide by 2:

In[10]:= %/2

      a/b
     E
Out[10]= ---- == x
      2

You can also add equations, etc.:

In[11]:= (a==b) + (c==d)

Out[11]= a + c == b + d

~ Roman M=E4der

CODE

(* :Title: make equations behave like lists *)

(* :Author: Roman E. Maeder *)

(* :Summary:
  make listable functions thread over equations as they do over lists.
  Allows for easy manipulation of equations.
*)

(* :Context: EqualThread` *)

(* :Package Version: 1.1 *)

(* :Copyright: Copyright 1997, Roman E. Maeder.

   Permission is granted to use and distribute this file for any purpose
   except for inclusion in commercial software or program collections.
   This copyright notice must remain intact.
*)

(* :History:
   Version 1.1 for mathgroup and MathSource, January 1998.
   Version 1.0 for DMUG (German Mathematica User Group), January 1998.
*)

(* :Keywords:
  Equal, equation solving, threading
*)

(* :Warning: Adds definitions to the built-in symbol System`Equal.
*)

(* :Mathematica Version:3.0 *)

BeginPackage["EqualThread`"]

(* no exports *)

Begin["`Private`"]

listableQ[f_] := MemberQ[Attributes[f], Listable]

protected = Unprotect[Equal]

Equal/: lhs:f_Symbol?listableQ[___, _Equal, ___] :=
    Thread[ Unevaluated[lhs], Equal ]

Protect[Evaluate[protected]]

End[]

EndPackage[]

I would say: Why D and Series do support Equal as an argument is more of a question, than why equal does not work with Plus.

It's not that Mathematica allows nonsense as True^2 or Cos[True], it just simple remains "unevaluated."

That's not how I would formulate it: It does allow for it and it remains unevaluated (i.e. it does not spawn an error like many other languages!).

Simplify[True^2 == True^2]

Equal just checks if the lhs and rhs are the same, nothing more. So it still does not interpret it here as a boolean or whatever.

But the best practice is, when solving manually, stop when things evaluate to True :).

I agree but if you have some automated script that takes user-input (an equation). and you want to work on it reliably it is tricky, because that would involve constantly checking if it is evaluated to True or False or unevaluated.

I think they never will: you should see equations as things that are either True, False, or Unevaluated. For the unevaluated case discussed above it makes sense to add '1' to each side, or to square both sides. However, for the True and False case, this does not make any sense. What is True + 1?

One could argue that Series[False, {x,0,1}] and D[True, x] doesn't make sense since False or True are not numbers. Hence they cannot be "constant" or anything whatsoever unless you have a very loose definition to account this.

It's not that Mathematica allows nonsense as True^2 or Cos[True], it just simple remains "unevaluated."

Other nonsense examples are Simplify[True^2 == True^2] which evaluates to True. Sometimes Mathematica knows True is boolean and sometimes it just thinks it is a Symbol.

So, there are many instances where True is treated as a constant, even though it is not a number (any Symbol is a constant in the view of D).

But the best practice is, when solving manually, stop when things evaluate to True :).

I don't understand yet why D does work to be honest… seems, at first sight, 'off'

You can only do one operand at the time using the above code, so you would need nesting, e.g.:

Thread[eq + Thread[-eq2, Equal], Equal]

first 'minus' then 'add' or first multiply then add…

You can 'edit' equations using Thread:

There are countless ways of parsing it. Thread is a very nice one (I'll be using it sometimes)! But I really don't like those large equations.

But I really don't get it. You can differentiate an Equal equation (you can't integrate though...), you can use Series with it, and possible others functions can operate on it, but you can't add a constant to both sides...

You can 'edit' equations using Thread:

eq = a == c + b
eq2 = g == h + k
Thread[eq + 3, Equal]
Thread[eq*2, Equal]
Thread[eq^2, Equal]
Thread[Log[eq], Equal]
Thread[eq + eq2, Equal]

It is a bit cumbersome, but it nicely extends to 'equations' of larger size: a == b+c == d+e+f

"Oh, behave!"

If you get the reference. ;)

Unprotect@Equal --- you like to live dangerously ;-)