`get_chunked_array_type` rejects two array classes handled by the same chunk manager

What happened?

We register a chunk manager that handles more than one array class.
A Dataset holding two of them raises TypeError: Mixing chunked array types is not supported on load.

get_chunked_array_type compares type(a) across the arrays, so two classes look like two frameworks.
Our manager recognizes both of them, its is_chunked_array is an isinstance check against several classes. The docstring describes the check as catching a mix of cubed and dask, but reading other threads about the chunk manager stuff makes me think this might be an oversight?

DaskManager also recognizes more than one class, its is_chunked_array asks whether the object is a dask collection, so the example below shows the same failure with nothing but dask.

What did you expect to happen?

The load to succeed, since one chunk manager handles both arrays.

I would still expect a TypeError for a real mix of frameworks, a dask array together
with a cubed array.

Minimal Complete Verifiable Example

# /// script
# requires-python = ">=3.11"
# dependencies = [
#   "xarray[complete]@git+https://github.com/pydata/xarray.git@main",
# ]
# ///
import dask.array as da
import numpy as np

import xarray as xr


class MyDaskArray(da.Array):
    pass


plain = da.from_array(np.array([1, 2, 3]), chunks=(1,))
subclass = MyDaskArray(plain.dask, plain.name, plain.chunks, plain.dtype)

xr.Dataset({"a": ("x", plain), "b": ("x", subclass)}).load()

Steps to reproduce

No response

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

Traceback (most recent call last):
  File "issue.py", line 20, in <module>
    xr.Dataset({"a": ("x", plain), "b": ("x", subclass)}).load()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File ".../xarray/core/dataset.py", line 593, in load
    chunkmanager = get_chunked_array_type(*chunked_data.values())
  File ".../xarray/namedarray/parallelcompat.py", line 162, in get_chunked_array_type
    raise TypeError(
        f"Mixing chunked array types is not supported, but received multiple types: {chunked_array_types}"
    )
TypeError: Mixing chunked array types is not supported, but received multiple types: {<class '__main__.MyDaskArray'>, <class 'dask.array.core.Array'>}

Anything else we need to know?

Grouping the arrays by the chunk manager that claims each one, rather than by their type, would fix it and still catch a dask/cubed mix.

Happy to open a PR if that sounds right.

xref: #8733 (I work with Mark but stumbled on this myself)

Environment

INSTALLED VERSIONS
------------------
commit: None
python: 3.13.15 | packaged by conda-forge | (main, Aug 10 2026, 13:05:01) [GCC 14.4.0]
python-bits: 64
OS: Linux
OS-release: 7.0.0-30-generic
machine: x86_64
processor:
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: ('en_US', 'UTF-8')
libhdf5: 2.1.0
libnetcdf: 4.10.1

xarray: 2026.7.1.dev41+gb1c1dc549.d20260820
pandas: 3.0.5
numpy: 2.5.2
scipy: 1.18.0
netCDF4: 1.7.4
pydap: 3.5.10
h5netcdf: 1.8.1
h5py: 3.16.0
zarr: 3.3.0
cftime: 1.6.5
nc_time_axis: 1.4.1
iris: 3.16.0
bottleneck: 1.6.0
dask: 2026.7.1
distributed: 2026.7.1
matplotlib: 3.11.1
cartopy: 0.25.0
seaborn: 0.13.2
numbagg: 0.9.4
fsspec: 2026.7.0
cupy: None
pint: 0.25.3
sparse: 0.19.2
flox: 0.11.2
numpy_groupies: 0.11.3
setuptools: 84.0.0
pip: None
conda: None
pytest: 9.1.1
mypy: 2.3.1
IPython: 9.16.1
sphinx: None

Start in xarray/namedarray/parallelcompat.py at get_chunked_array_type and compare its type-based check with the manager recognition in xarray/namedarray/daskmanager.py. Run the provided MVCE to reproduce the failure. Done means arrays handled by one chunk manager load successfully while a genuine dask/Cubed mix still raises TypeError.