RE: SVG 1.1 Spec Rec - 7.6 The Transform Attribute

Think you were wrong?  I don't think so.
Your simple example is excellent.
Let me paraphrase it and walk through it.

Take a rectangle at (0,0) of width and height 30.
Translate it to (200, 0)
We then have a rectangle at (200, 0) of width and height 30.
Now rotate that rectangle by 45 degrees (about 0,0). (remember the rectangle now has an upper left at 200,0 and lower right at 230,30)
What do we expect? We expect the upper left and upper right points of the square to lie along the 45 diagonal passing through 0,0
i.e. the rotation is about 0,0 not 200,0. The upper left conner will be a distance of 200 from 0,0.

That is not what Adobe SVG or Amaya does. 

I have added some code to your example to illustrate the "steps" the rectangle should take.
Interestingly Adobe rotates a rectangle defined at 200,0 correctly, but not a rectangle translated to 200, 0

Understanding this problem has nothing to do with matrices - 
they are often used as tool to solve transformation problems but 
are NOT inherently need to solve the problem. 

As Chris points out in his paper: (and made in the classic texts on the subject e.g. Foley, VAN DAM)
For Translation
 X' = X + t(x) 
 X' = X + t(y)
 and for rotation
 X' = X * cos(angle) - Y*sin(angle)
 Y' = X* sin(angle) + Y*cos(angle)
Applying these in the order provided for the "upper left" yields

Translation
X' = 0 + 200 = 200
Y' = 0 + 0    = 0
then
Rotation ( about 0,0 )
X'' = 200*cos(45 deg) - 0*sin(45 deg) = 200*.71 = 141.
Y'' = 200*sin(45 deg) + 0*cos(45 deg) = 200*.71 = 141.

What you have guessed is that the viewers are performing rotation then translation. 
i.e. they are applying the transformations in the opposite order to the order to which they are provided.
(There is another option here, but it nets out the same for this discussion)

As has been noted the spec states:
If a list of transforms is provided, then the net effect is as if each transform had been specified separately in the order provided. 

Since English is read from left to right ( and right or wrong SVG is in English) the order your example provides is translate then rotate. 

The spec should not be compromised by the implementation. 
Interpreting the spec according to "matrix order rules" (backwards to English?) is interpreting the spec based on using a matrix based implementation. This is highly confusing, and inappropriate. 
Further since the matrix order for pre-concatenation is opposite to post-concatenation the spec would have specify pre or post rules. 

This is all to say the "English rules" should rule and the viewers are not performing to the specification. 

Here is Patrick's example with a few steps added in green.

<?xml version="1.0" encoding="UTF-8"?>
<svg width="100%" height="100%" xmlns="http://www.w3.org/2000/svg">
    <rect width="30" height="30" fill="green" />
    <rect x="200" y ="0" width="30" height="30" fill="green" />
    <rect x="200" y ="0" width="30" height="30" fill="green" transform="rotate(45)"/>
    <rect width="30" height="30" fill="orange" transform=" translate(200,0) rotate(45)"/>
 <line x1="0" y1="0" x2="200" y2="200" stroke="gray" />
</svg>

I would be happy to provide additional SVG test  cases for the viewers.

I look forward to the responses.
Thanks, ian