Well, I just read the thread and I do not see any urgency about the proposed changes. It is well known that vararg should never be used in high performance operation due to additional array allocation, but I do not see any real use case for it in those operations. To achieve high performance you should always use manual array allocation and then pass this array to a function. Also, one should note that if we are talking about performance, only primitive arrays count. If we are using boxed values, typed list is preferred in most cases since it gives additional type safety for mutating operations and is more flexible in general.
Introducing new language construct just for optimizing vararg seems to be rather bad idea. It does not worth it. As I already said, one just should not use varargs in performance bottlenecks. Some optimization without actual language changes could be made under the hood, but I do not see it as a critical problem. I would second a request for a real life use-case, where this performance matters.
The final point is the important thing people usually forget about: inlines are not for performance. In most cases inlining functions does not increase performance on JVM. In many cases, on the contrary, it decreases it. The only two regular cases, where inlining is needed are lambda inlining and generics in primitives. Of course, outside JVM compile is not so smart. But performance on JS is a joke and native is not ready for performance optimization anyway, so we should not start with language features.