A couple good questions were posed today on Reddit: "I see the change so it now instead of saying mdspan is incompatible with GPUs, it says it is but in a way that is "ad-hoc, needs markings, [and has] no pointer-type propagation" in contrast to Boost.Multi which is "via flatten views (loop fusion), thrust-pointers/-refs". Those terse words pack a lot of meaning, which I spend a while pondering, but I expect I could spend several weeks fleshing out more fully if I had the time! I think "needs markings" refers to code using mdspan needing annotations like __device__, although I see such annotations in the examples in CUDA examples of Boost.Multi's docs (as well as in Boost.Multi's library code itself), so I am unsure why mdspan code would be described as "needs markings" but not Boost.Multi. But more broadly, I think I see the idea is that Boost.Multi has more pythonic ergonomics, whereas mdspan is more a flexible vocabulary type with roughly zero overhead. This raises the several questions I don't see answered in Boost.Multi's docs: (1) How much overhead does using Boost.Multi add to GPU work compared to raw pointers or mdspan? The mdspan paper has microbenchmarks comparing it to raw pointers, showing it adds roughly zero-overhead. Getting that to be the case drove much of the design of mdspan. (2) How big of an advantage are Boost.Multi's ergonomics? When I read that mdspan lacks "thrust-pointers" it isn't obvious to me if that matters or not. I think perhaps an example showing the core ergonomic advantage of Boost.Multi could help clarify this. That would also help clarify if the limitations to mdspan are fundamental or it just needs some helper code which could be libraryitized. Which brings me to the final question -- (3) Should Boost.Multi be built around the std::mdspan and std::mdarray vocab types? It is preferable to use standardized vocabulary types unless there is a good argument why not, and in this case, I cannot tell if there is. An AccessorPolicy to mdspan can customize it with non-raw handles and fancy references, so Boost.Multi's doc saying mdspan doesn't support "pointer-type propagation" isn't quite right, it just needs some helper code in a library somewhere to make that happen. Could Boost.Multi be written to be that helper code, and if so, would that be a better approach?" Below is Alfredo's response to the above post: " 0) “needs markings” means “needs a custom version of mdspan with markings” 1) no expected overhead, all specifics of GPU pointers are compile time. GPU arrays are recognized as GPU by its pointer types; there is no runtime metadata on them. if mdspan accessor parameter can control the pointer types and that can be done easily I would say is not different then. 2) ergonomics: Multi works with all STL algorithms, all Thrust algorithms, (dispatching can be automatic and compile-time), and all Ranges algorithms 3) Multi should be interoperable with mdspan (and it is) and future mdarray. Implemented based on them? is not something practical, first because it will depend on the C++ version when they are available, also there are specific choices that makes it extremely difficult such as retrofitting iterators on mdspan and changing the “pointer” semantics of mdspan. mdarray is an adaptor on top of a container, this is quite a different approach than the one taken by Multi, that affects the level of control of initializing data. Implementing Multi on top of mdspan and mdarray would be fighting up hill. also will need to coordinate mdspan and mdarray which are separate sublibraries, one of which is only available in C++26. " Matt