Thanks for working on this!
The proposed solution is not going to eliminate this in all cases. It introduces the #variadic syntax at the usage site which will sometimes be considered unacceptable. On the other hand, the proposed solution is probably the best we can do with the existing variadic syntax given the source compatibility constraint.
I would really like to see enhanced variadics happen eventually. Even if that pitch does move forward, this pitch fills an important gap, a gap that cannot be filled by enhanced variadics. Specifically, public variadic methods that do not provide an array-accepting overload are sometimes entirely unusable with array values as it is not always possible to write an array-accepting overload outside the module.