@wadetregaskis
Regard your first post, I think that in another thread there was a discussion about the variadic-are-tuples argument. It seems to me that there is desire (and advantage) to keep built-in tuples and this new concept of "variadic-tuple" separated.
What you suggest I briefly mentioned in the #head, #tail, #length, #reduce, #ifempty section of the latest version of the document. The problem I mention there (conflict between the built-in Collection methods of the variadic tuple and members with the same name on the common supertype) obviously only occurs if we have the magic . syntax access, which you suggest to remove. I have not explored a design in which variadic tuples are only Collections and nothing else, it might be interesting to reason about.
About your second post, personally I think that the gains we might have using glob syntax are not worth the implementation required, especially because I cannot find (but that's just me) a reason to limit the number of variadic parameters in a specified range. The * vs + to indicate 0... or 1... is interesting, but I'm not sure if a single character really stands up to indicate what's happening (variadic generic plus specification on the minimum number of parameters required). Maybe if this is a real problem while designing APIs we should find another solution.
Sure your suggestions may be worth the addition in the Alternative Considered section! Thank you for your feedback!