This includes popular numerical frameworks one might erroneously assume from
their names to be Python-specific like PyTorch. Despite the name, PyTorch is
also implemented as a low-level Python-agnostic C++ layer
(https://pytorch.org/tutorials/advanced/cpp_frontend.html). The same goes for:
* The entirety of TensorFlow's core C++ API
(https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/framework).
* *Most* but not all of NumPy's core C API
(https://numpy.org/doc/stable/reference/c-api/coremath.html), which NumPy
developers are desperately refactoring to be Python-agnostic. I believe the
core "numpy.core._multiarray_umath.ndarray" type is still Python-specific,
but that's likely to change sometime this decade. (Don't quote me on that.
Please. My GitHub karma can only take so many body blows.)
As a member of the NumPy core team, let me set the record straight: NumPy is not and will never be Python agnostic. NumPy's internals are specialized to Python's C API. There are many wonderful multi-language numerical computing frameworks, but NumPy is not one of them. I'm not sure where you got this idea but it isn't true.
From a performance perspective, I doubt there are any fundamental issues. Python itself (since Python 3.9) comes with quite a few types defined in C that support type annotations. The ndarray objects in NumPy and other numerical computing frameworks are quite similar in spirit and implementation to Python's built-in types.
Your extensibility concerns are legitimate, but they aren't really specific to multi-dimensional arrays. The data structures behind NumPy have been around for decades, again just like Python's builtins.