@eteq @crawfordsm -- FYI, I am holding off on implementing ``__mul__`` and friends for the moment. 

The problem isn't with *how* to do it -- it is easy enough to write the method to allow for multiplication by a scalar or another ``CCDData`` and propagate the error correctly in both cases...and in principle multiplication by a ``Quantity`` can be handled too.

However, until ``NDData`` and ``Quantity`` better coexist it is impossible to make sure that something like ``(1.5  * u.ph/u.adu) * ccd_data_object`` returns a ``CCDData`` object. In this case the fact that ``Quantity`` defines ``__mul__`` means that *its* multiplication method gets called and the result is a ``Quantity``. Multiplying in the opposite order returns a ``CCDData`` object, rendering multiplication non-commutative.

What I've done for now is overridden the ``multiply``, etc., methods from ``NDData``. They check for the case of multiplication by a scalar or ``Quantity`` and handle that case, with multiplication by another ``CCDData`` passed off to ``super``.

Just to be clear, I am not at all opposed to implementing ``__mul__`` and friends -- in fact, I would prefer it and went down that road first! But for now I can't control how ``__mul__`` behaves.

Actually, I *could*, I suppose, by removing the ``__array__`` method from ``CCDData``. Then ``Quantity``'s ``__mul__`` ought to fail.

**Speak up if that would be the preferred behavior** -- doing so would not, I think, interfere with slicing, which is implemented in ``NDData.__getitem__``.