My initial changes to the internal use of __quantity_view__, __quantity_instance__ and __array_wrap__ in Quantity caused problems in Coordinates and upon closer inspection I noticed they problems all were due to these methods being used incorrectly in CartesianPoints. In particularly, unlike what one might infer from the name, __quantity_instance__ and __quantity_view__ are not meant to return Quantity instances/views of oneself, but rather to allow one to fall back to one's superclass if desired. It was more or less invented for Angle, where if a unit is no longer an angular one, a Quantity is returned, as shown below. @eteq - I'm fairly sure my corrections to CartesianPoints are correct, but please check.

@mdboom, @astrofrog - we may need to change the names of these methods. It may be worth thinking a bit more generally if it is the right approach.

    def __quantity_view__(self, obj, unit):
        unit = self._convert_unit_to_angle_unit(unit)
        if unit is not None and unit.is_equivalent(u.radian):
            result = obj.view(self.__class__)
            return result
        return super(Angle, self).__quantity_view__(
            obj, unit)

    def __quantity_instance__(self, val, unit, **kwargs):
        unit = self._convert_unit_to_angle_unit(unit)
        if unit is not None and unit.is_equivalent(u.radian):
            return self.__class__(val, unit, **kwargs)
        return super(Angle, self).__quantity_instance__(val, unit, **kwargs)

travis failures are due to timeouts; can ping travis once people have commented.

@mdboom - I realised my chain of PRs was hopeless for making any changes, and so pulled it apart. This one now only addresses better use of __array_finalize__ and __array_wrap__ in Quantity and its subclasses. I implemented an extra comment you asked about in #1851, and used str() in the dtype definition.

I'm inferring from some of the comments you made above that @mdboom said something about this, but I can't see what... Your changes to CartesianPoints do make sense based on the explanation here, but it would be good if @mdboom could glance at them to make sure that's what was inteded for those methods.

@eteq - the __quantity_view__ and __quantity_instance__ go back to when we made Quantity an ndarray subclass (#929). But it would be great to have others look at it; this was a somewhat unexpected deep-end plunge.

Makes sense to me.

Just to be sure, since quite a few Quantity PRs were merged, I rebased. Seems all OK.

@eteq - does my explanation of the changes make sense? Do you think this is OK to go in? Longer-term, may need to reconsider the set-up (see #1850), but at least this should make things a bit more robust.

Sure, I think this is fine, @mhvk - will go ahead and merge it now. We can have further discussion on more general points in #1850 and the upcoming coordinates APE/API.