iirc this is because we made order part of the runtime configuration, due to order not being part of the zarr v3 metadata model. I'm pretty sure a global config is the wrong location for this parameter -- I think we need a per-array namespace for runtime configuration like this.

It's part of the v2 metadata though, so shouldn't this be persisted and read in with the array itself (for zarr format 2)?

if you inspect the array.metadata.order, I think you should see that it has the expected F value. The issue is that when zarr opens an array, it defers to the global config when setting the order of the in-memory array associated with that zarr array, whether the array is v2 or v3. The problem is our use of this global config.

if you inspect the array.metadata.order, I think you should see that it has the expected F value.

Nope, arr.metadata.order still gives the wrong order.

:( that's bad! we definitely need to fix this!

i can get to this in the next few days unless someone does it first

if you inspect the array.metadata.order, I think you should see that it has the expected F value. The issue is that when zarr opens an array, it defers to the global config when setting the order of the in-memory array associated with that zarr array, whether the array is v2 or v3. The problem is our use of this global config.

this explanation is actually very wrong -- we are already using the array-specific config. the underlying issue, addressed in #2951, is a simple bug in our implementation.