I can see the utility in this but I'd change the implementation a little bit personally. Additionally, there are some consequences to this change that you might not know about as well, I'l try to explain here:

A bit of context first: The previous consumer iteration just had the one chunk for geographical coordinates. This was fine becase at any given point when making the dataset, all of that data was available to be written. This is because the old consumer would pull all the raw data, merge it all in memory, and then write it to the store. The pre merge was memory intensive and slow, but it meant for certain that that whole chunk of all the geographic data would always be written all at once.

The new consumer doesn't do this - it pulls the raw files and writes them on the fly to specified regions of the store, which its what enables parallel processing. However for this to be safe, it has to be the case that each individual write is covered by a chunk, i.e. no chunk can be bigger than the data that is expected to be recieved by a single file. See

Concurrent writes with region are safe as long as they modify distinct chunks in the underlying Zarr arrays (or use an appropriate lock).

from https://docs.xarray.dev/en/stable/user-guide/io.html?appending-to-existing-zarr-stores=#distributed-writes

Mostly, sources of NWP data provide files per parameter, so as long as there is one parameter per chunk in the store, they can be written in parallel. But some (ceda for one) split their files by areas, so there are four files each covering a different geographical region. As such, there has to be at least four chunks per geographical coordinate in the store, whether its being saved to S3 or otherwise, or else the regional writing will be broken.

The long and short of this is that the default chunking modification isn't a coordinate issue, but a RawRepository one - it depends on how they provide thair data. By using 8 by default I had a catch-all for everything we covered so far, but I appreciate that is only necessary for the ones that provide multiple area files. As such, I think this PR should be slightly reworked to modify where this logic is carried out, away from the NWPDimensionCoordinateMap class and into the RepositoryMetadata. Alternatively, we can drop the chunk size down to be equal to the length of each coordinate but use an appropriate lock as instructed by the docs? But this might lose us some concurrency performance gains.

I'm happy to make the changes - hopefully my reasoning above makes sense?

Yea, it seems a long way round to do it, but I couldnt quite work out how to change it otherwise. Perhaps there's a way you can modify it