> template<typename... Ts>
> class tuple {
>   Ts... elems;
> };

This is a thing of beauty :-)
The only drawback: I would actually like to be have "real" names for
members. That would allow to use

    auto x = t.m1;

instead of

    auto x = get<1>(t);

In my view, we should be able to treat tuples as structs and structs as
tuples. We just spell them differently. For instance, std::get would
work with structs. And I could also pass structs into tuple_cat.

Naming members of tuple falls into that category of "the next problem". We can do this with injection, but it can be much less elegant. Fortunately, we have functions to hide complexity.

template<typename... Ts>
struct tuple {
  consteval -> gen_tuple_members(^Ts...);

We should be able to make std::get<> work with structs with just reflection:

template<std::size_t N, plain_struct T>
decltype(auto) get(const T& obj) {
  return obj.[:data_members_of(^T)[N]:];

That can get a little more complicated when you add inheritance and access specifiers, but not much. Although, now that I think about, we could just replace the usual definition of std::get with something like this, and it automatically works for both tuples and structs. A little constexpr if sprinkled in there also makes it work for arrays.

I will continue avoiding tuple cat for now :)

(Every time I see "tuple cat" or tuple_cat, I keep wanting to read it as "Honky Cat", as in the Elton John song).

> constexpr tuple(T const&... args)
>   : ... [: data_members_of(^tuple) :]([:parameters_of(current_function()):])
> { }

While Barry's proposal is much shorter, I would prefer something like
this, as it would work with named members :-)

The idea of declaring packs vs. naming members is interesting. There are design objectives that motivate both uses, but I don't know if there are obvious criteria that push a design in either direction. Maybe it's just "I want names" vs. "I don't care about names".

So yes, go and find examples that are hard/clumsy without reflection and
start translating them. We need real life examples :-)

My experience has been that it is very hard to simultaneously design and implement language features and also dogfood them. It's also more than a bit self-reinforcing. Having other people bring problems --- which you have a great history of :) is excellent fodder for design discussions.