Is this a spec change?

Going to check.

(sorry, only old spec is at hands reach now)

C.4.8: The decoder shall decode a modular sub-bitstream (C.9). However, the decoder shall only decode the first nb_meta_channels channels and any further channels that have a width and height that are both at most 256.

C.8.2: In the partial image decoded from the GlobalModular and ModularDcGroup sections, the pixels in the remaining channel data that correspond to the group are decoded as another modular image sub-bitstream (C.9)... The number of channels and their dimensions are derived as follows: for every remaining channel in the partially decoded GlobalModular image (i.e. it is not a meta-channel, the channel dimensions exceed 256×256,...

C.9.2: The decoder shall then decode the data for each channel (in ascending order of index) as specified in C.9.3, skipping any channels whose width or height is zero. Finally the series of inverse transformations shall be applied as described in C.9.4.

So, both C.4.8 and C.8.2 add "extra" condition on the top of C.9. C.9.2 gives a lower level hint - "no pixels -> skip".

But of course, that could be interpreted the other way round.

@jonsneyers friendly ping

I mean: are there files produced by older cjxl/libjxl that will no longer decode if this gets merged, or will the new cjxl/libjxl produce files that will not decode by older djxl/libjxl?

Current encoder and decoder fail when they meet specific input (very tall/wide image + modular + group-shift).
So, likely there are no such files in the wild.
New encoder will be able to produce files on which old decoder will fail.

Context: #3937

OK, let's just check if this is something that needs to be made more clear in the spec.