Slightly soften the warning at the beginning of the modeling docs; some
turbulence should still be expected, but not as *much*, at least not for
the most common use cases, and I want to give more of a guarantee of
backward compat support as much as possible.  I don't want to scare
people away from getting what they can out of this. [ci skip]
Adding a little more info to this test's docstring
To explain this commit, I'll just copy from the e-mail response I sent
to the original report of this issue, explaining how I solved the
problem:

As I suspected, this had to do with a concession I had to make way back in this PR:

https://github.com/astropy/astropy/pull/2634

This concession is mentioned in the section of the PR text "Caveats" under item
3.  The rules I came up with for broadcasting arrays work for the vast majority
of models, but there are some (particularly ones like AffineTransformation2D
that involve multiple coordinates) where they don't quite work.

As a temporary workaround I added a `standard_broadcasting = False` flag to
these models--this allows them to opt out of the standard assumptions (and, if
they wish, implement their own prescriptions by overriding prepare_inputs and
prepare_outputs).

The trick here was to make sure that a compound model containing
AffineTransformation2D (or others like it) propagate the
 `standard_broadcasting = False` flag.  If one model in a compound model has
this limitation, then it must, for now, be applied to the entire model.

In the near future I hope to do something a little less brute-force here.  I
envision models being able to provide some sort of broadcast_hints data
structure, which I think can be fairly simple.  Most models wouldn't need to
use this (the defaults are fine).  But this could explain to the code exactly
what inputs and parameters are used with each other, and how they should fit
with each other.  (Obviously reimplementing prepare_inputs/outputs could do
this too, but I think the realistic cases are still limited enough that this
can be done in a declarative manner and avoid having to reimplement lots of
code over and over again).

In the meantime, the fix I will add shortly should be good, I think, for most
cases we care about?