Davis Bennett

that means that `ZipStore` always errors if it reaches this conditional in `make_store_path`: https://github.com/zarr-developers/zarr-python/blob/4c3081c9b4678d1de438e0d2ee8e0fa368a61f17/src/zarr/storage/common.py#L224-L227 If we want to keep these store semantics (I'm not sure that we do...) we should...

would it be terrible if `ZipStore.with_mode(self, mode)` called `self.close()`, effectively invalidating the original store instance?

upon calling `_sync_open`, `ZipStore` instances acquire a lock and a file handle: https://github.com/zarr-developers/zarr-python/blob/4c3081c9b4678d1de438e0d2ee8e0fa368a61f17/src/zarr/storage/zip.py#L86-L93, so I think it's about as stateful as you can get.

yes, this was partially fixed in #3422, but we still have an extra `get` in the output you generated. It's unnecessary because we are writing a complete shard, and so...

thanks for this report! I suspect this won't be too much work to fix; I'll try to get something out soon

> I suspect this won't be too much work to fix how wrong I was... this issue exposed two problems: - the `numcodecs.delta` codec uses NumPy data types, but we...

yes, effectively every dtype-sensitive codec in `numcodecs.zarr3` is broken because of the recent dtypes change. we have to resolve #3261 and / or push a fix to numcodecs before this...

i have a fix in https://github.com/zarr-developers/numcodecs/pull/766

thanks for this example @dtonagel! I'm guessing the culprit is some assumption in the [`vlen-utf8` codec](https://github.com/zarr-developers/numcodecs/blob/b543298ebaa47608065c57893c1709d6523f6b6b/numcodecs/vlen.pyx#L48) we are using here

thanks for this report -- I think this is likely an fsspec issue? cc @martindurant