mfdataset using glob syntax from S3 not working since zarr v3

What happened?

Hello,
Since the package update to implement the new zarr specification, the glob syntax for loading S3 files is not working anymore.

For example, the following code:

import xarray as xr

xr.open_mfdataset("s3://mybucket/myzarr/*.zarr", engine="zarr")

no longer works. The error is the following:

TypeError: Unsupported type for store_like: 'FSMap'

Reading the latest documentation, I see that you now suggest the explicit utilization of a mutablemapping instance. In my case, I would have to do something like this:

from s3fs import S3FileSystem
import xarray as xr

s3 = S3FileSystem()
xr.open_mfdataset(["s3://" + file for file in s3.glob("s3://mybucket/myzarr/*.zarr")], engine="zarr")

All of a sudden the code becomes twice as long, I have to import s3fs explicitly and use a list-comprehension to append the "s3://" prefix to the file names.

Are you planning to re-implement the old behavior? There is something that I'm missing here?

What did you expect to happen?

I would expect the previous syntax to remain working.

Minimal Complete Verifiable Example

MVCE confirmation

• Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray.
• Complete example — the example is self-contained, including all data and the text of any traceback.
• Verifiable example — the example copy & pastes into an IPython prompt or Binder notebook, returning the result.
• New issue — a search of GitHub Issues suggests this is not a duplicate.
• Recent environment — the issue occurs with the latest version of xarray and its dependencies.

Relevant log output

Anything else we need to know?

No response

Environment

Start by reproducing the reported call to xr.open_mfdataset with engine="zarr" and the S3 glob pattern from the issue, using the stated xarray, zarr, fsspec, and dask versions. Trace how the glob path is handled before the zarr store is opened. Done means the previous S3 glob syntax works again without requiring the explicit s3fs glob-and-list workaround, with regression coverage for this case.