> See the lines of interest, below (lats is per-point, not a unique ascending list):

I'm pretty sure `jDirectionIncrementInDegrees` is guaranteed to be positive, even for north-to-south grids. Therefore `y_step` is always positive and `new_lats` may actually be incorrect, so not just upside down but plain wrong? See the way increments and scanning modes are handled hand-in-hand in the [iris GRIB load code](https://github.com/SciTools/iris/blob/master/lib/iris/fileformats/grib/__init__.py#L485-488).

>  Regardless, I can't find an example of -ve j step in a thinned grid

The files I work with from ECMWF are always north-to-south grids, but as I suggested before they have a positive increment and use the scanning flag for direction. For a regular 2.5 degree grid with latitudes north-to-south I have `jDirectionIncrementInDegrees = 2.5` and `jScansPositively = 0`. 

> I'm still getting a feel for how to balance focused agile development against general robustness for a global community.

I think this might be a genuine bug, I don't think this has anything to do with agile development because it is not just leaving some extra functionality for later, but potentially creating a bug to be tracked down later.