Good thoughts.
 
And I'm concerned about implicitly treating both ranges and packs the same. I think this could run into similar issues as we saw with expansion statements, and similar issues to the case I talk about in P1858 (the context here was directly expanding a tuple into its underlying parts, which is similar to expanding a range of meta::infos into its infos):
template <typename T, typename... U>
void call_f(T t, U... us)
{
    // Is this intended to add 't' to each element in 'us'
    // or is intended to pairwise sum the tuple 't' and
    // the pack 'us'?
    f((t + us)...);
}
Here, it's easy for me to come up with examples of wanting either choice:
* call_f(tuple(1, 2), 3, 4) could be intended to call f(4, 6), doing the pairwise sum.
* call_f(point{1, 2}, point{0, 1}, point{3, 7}) could be intended to call f(point{1,3}, point{4,9}), adding 't' to each element.

I think the issues expanding ranges are a little different than with the issues in the original expansion statements. I also think the expansion here is perfectly clear (for some definition of perfect and clear). It's always the 2nd behavior.

See my other post. If you wanted the first result, you would need to nominate t as being expandable:

    f((...t + us)...); 


A similar thing could come up here - where we have a range of meta::info and a pack and may want to expand the range and may not want to:

template <typename E, typename... Args>
void foo(Args... args) {
    constexpr auto enums = meta::enumerators_of(reflexpr(E));
    g(|impl(enums, args)|...);
}
enum E { A, B, C };
void bar() {
    foo<E>(1, 2, 3);
}

Are we calling impl(enums, 1) or are we calling impl(reflexpr(E::A), 1)?

The former. Writing this:

    g(|impl(...enums, args)|...);
 
would give you a splice with 2 unexpanded packs (enums) and args and you'd get:

impl(^A, ^B, ^C, 1, 2, 3);

 Andrew