Regarding the failing tests, it seems clear that the test integration.load_convert.test_data_section.TestDRT3.test_grid_complex_spatial_differencing is now failing because when you load the 'missing_values' file, it now gets an extra 'unknown' vertical coordinate, which looks like this :

>>> path = tests.get_data_path(
...     ("GRIB", "missing_values", "missing_values.grib2")
... )
>>> cube = iris.load_cube(path)
>>> print(cube)
x_wind / (m s-1)                    (latitude: 73; longitude: 144)
    Dimension coordinates:
        latitude                             x              -
        longitude                            -              x
    Scalar coordinates:
        forecast_period             0 hours
        forecast_reference_time     2013-05-21 00:00:00
        time                        2013-05-21 00:00:00
        unknown                     1829.0
    Attributes:
        GRIB_PARAM                  GRIB2:d000c002n002
>>> print(cube.coord('unknown'))
DimCoord :  unknown / (unknown)
    points: [1829.]
    shape: (1,)
    dtype: float64
    attributes:
        GRIB_fixed_surface_type  102
>>> 

Checking what this used to do, it did not previously have the extra "unknown" coordinate.

So, I guess this is intentional, but also it is a breaking change.
Are we comfortable with this @lbdreyer, or do we need to control this somehow to preserve behaviour ?
It's a bit awkward : I guess it would need the equivalent of an Iris FUTURE flag. We don't really have a policy for how to do all that in iris-grib AFAIK.

So, I guess this is intentional, but also it is a breaking change.
Are we comfortable with this @lbdreyer, or do we need to control this somehow to preserve behaviour ?
It's a bit awkward : I guess it would need the equivalent of an Iris FUTURE flag. We don't really have a policy for how to do all that in iris-grib AFAIK.

I don't see this as a problem, and I don't agree that it is a breaking change. We are now supporting the loading of something that we previously were skipping. The old behaviour was just due to Iris-grib's limitations. This extends iris-grib's capability rather the changing it.

From a user's perspective, it may have an impact on how their cubes get loaded (e.g. a GRIB file with multiple heights now may be merged into a 3D cube rather than a list of 2D slices) but I see this as us correcting the behaviour.

This extends iris-grib's capability rather the changing it... I see this as us correcting the behaviour.

👍 If you're confident to label this as a "fix", then I'm OK with it + it is not "breaking" !

Thanks @lbdreyer I think this is fine now.