> Failing here does not denote an unreasonable cube, but an unreasonable request to save to grib2 (should we not choose the 'missing' option also discussed here).

The cube is valid and that there is a valid way to save it as a GRIB2 message; I'm not sure exactly what the appropriate encoding is but we will get to that, I find it nearly impossible to believe that failing at this point is the correct response to the 'save' request.

> Failing is the current behaviour. I asked about why we can't fail because I want to know what has changed in our requirements that means we have to change the current behaviour.

I think this behaviour is wrong and needs to change.  We have a clear use case for data where the phenomenon is defined but there is no 'z' type coordinate on the cube; this data is required to be exported as GRIB2 messages.

I feel we should find the correct encoding for this, then implement it appropriately. Patrick's approach looks valid, but a further opinion on the encoding would be of value here.  I have requested feedback from our colleagues at the ECMWF and I will report back on any insights they can provide.