A thought that just occurred to me, and might be worth exploring, is that we might want to draw a distinction between "general-purpose" const functions, that are just regular code that happens to have the "const" label, and "intended-for-generics" const functions.
The big difference would be that, while general-purpose const functions could panic like any regular function could, intended-for-generics functions would have to be guaranteed (who enforces it though?) to only panic with a compiler-friendly error message.
This could be like with unsafe code: generic-friendly code could call non-generic-friendly code with a may_raise_arbitrary_panics escape hatch; people reviewing the code would know that that hatch comes with obligation that the developer checks/proves that the inner code can never panic given the inputs of the outer code.
The way I was thinking, the MVP would add variadic parameters-packs as a syntax, while still only allowing them to be used in a way completely equivalent to variadic tuples.
(keep in mind that as long as a construct is syntax-only and not part of the type system, it can always be rolled back with an edition change)
As people start using them and corner cases are figured out, further RFCs would add more uses that aren't exclusively tuple-based. Tuple metaprogramming and stuff like (...my_tuple, ...my_other_tuple) would still no be added.
I don't really see any downside this has compared to a "variadic tuples plus tuples metaprogramming" approach (except in terms of flexibility, but I've already said why I don't think that's a plus).