On Tue, Nov 14, 2023 at 10:04 AM Hewill Kang via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
(1) [...] but that a multi-argument `.at(x,y,z)` would be completely novel in the STL and therefore very clearly "design work" not to be snuck in by LWG; it needs a paper. Such a paper seems non-controversial to me, but who knows.

This is a great point, thanks! I agree that variadic templates `at(...)` are *new* to the standard, and when I try to spell out the "*Effects*: Equivalent to:" wording that fits it, it's not as straightforward as it seems, which is indeed something worth considering.

So I think `mdspan::at` deserves its own paper, perhaps discussing the rationale for further providing `front()` and `back()`? Because in my opinion there is also value in these two, the former eliminates the need for spelling `ms[0,0,...]`, and the latter simplifies `ms[ms.extent(0)-1,ms.extents(1)-1,...]`, which may be convenient for users.

I don't think there's anything special about `ms[0,0,...]` or `ms[ms.extent(0)-1,ms.extents(1)-1,...]`. They certainly don't represent "front" or "back" in the same way as in a std::list, for example. They represent "upper left" and "lower right"... except that I think you might be able to set the layout policy so that they represent "lower left" and "upper right," or anything in between, maybe?
Notice that even e.g. std::set fails to provide front() and back() accessors. And there I've actually (more than once) wished for a front() accessor, as in "get me the least item in this ordered set"!
Personally I would like to have `front/back` for `set` and friends, but I see no benefit to `front/back` for mdspan.

Cheers,
Arthur