It could be worth noting that, even if it is nice if we support compile-time recursion like the one you showed, it could be important to support variadic fold expressions. Using the example from @Nemo157 as a base, something like
fn log<...Labels, ...Values>(labels: (...Labels), values: (...Values))
where
Labels: (X: Display; X),
Values: (X: Debug; X),
{
...eprintln!("{}: {:?}", labels, values);
}
This, intuitively, should resolve in something like
fn log<A, B, C, D, E, F>(labels: (A, B, C), values: (D, E, F))
where
A: Display, B: Display, C: Display,
D: Display, E: Display, F: Display,
{
eprintln!("{}: {:?}", labels.0, values.0);
eprintln!("{}: {:?}", labels.1, values.1);
eprintln!("{}: {:?}", labels.2, values.2);
}
This if we consider supporting multiple tuple unfolding in a single unpack.
There are two main reasons I am thinking about this possibility, based on my experience in C++.
The first thing because we are missing many things to access specific tuple elements using nonliteral notations. In details, at to date we must write t.N, where N is a valid index for the tuple. Unfortunately this doesn’t compose so well in terms of generic programming. Moreover, we still don’t have non-type generics, precluding the possibility of using compile-time indices to access specific elements of a tuple. Finally, variadic templates existed since C++11, but until the introduction of std::integer_sequence in C++14 writing folding/recursive things like in the example was a real pain.
In Rust we have a powerful macro ecosystem, and maybe it is possible to assess some of these situations without compiler support. Nevertheless, I would really like a deep analysis of what this proposal could allow by itself, which situations could be supported from external crates (with macros and procedural macros) and what will not be possible without further improvements.
Ok, second observation. This is a minor issue from some points of view, a major one from others. C++17 introduced fold expressions for two main reasons: better code and better compile-time performance. Obviously I am thinking about the compilation times. Indeed, before fold expressions all the template instantiations were performed recursively, and this caused a huge impact on compile performances.
If we introduce variadic generic with the support for recursiveness but without folding expression support, I think that we will end up with slowdown at compile-time very soon (everything that nowadays is implemented using macro builders will probably use variadics).
Sorry for the long post, but I am quite interested in this proposal, and I would like to fully understand the actual possibilities and aims.
EDIT: ok, maybe it is good to show some example of what can be done in C++, with the good, the bad and the ugly syntax 
// Return true if all values can be implicitly converted to bool(true)
template <typename... Ts>
auto all_of(Ts... ts) {
return ( ts && ... );
}
// Sums all the values, starting from 0
template <typename... Ts>
auto sum_all(Ts... ts) {
return ( 0 + ... + ts );
}
// Sums all the values, but the first value is the first given parameter
template <typename T, typename... Ts>
auto sum_all2(T t, Ts... ts) {
return ( t + ... + ts );
}
// Print all the elements without separators
template <typename... Ts>
void print_all(Ts const &... ts) {
(std::cout << ... << ts);
std::cout << '\n';
}
// Print all the elements using a space as separator
template <typename T, typename... Ts>
void print_all_sep(T const & t, Ts const &... ts) {
std::cout << t;
((std::cout << ' ' << ts), ...);
std::cout << '\n';
}
// Print the index for every element and the element itself for every line
template <typename... Ts>
void print_all_with_index(Ts const &... ts) {
// This not even C++17, it's C++20...
[]<std::size_t... Indices>(auto&& args, std::index_sequence<Indices...>) {
((std::cout << Indices << ' ' << std::get<Indices>(args) << '\n'), ...);
}(std::make_tuple(std::cref(ts)...), std::make_index_sequence<sizeof...(Ts)>());
}
As you can see, the first 4 example are quite nice, but the others… 
