Is the last print statement the only thing that ensures that
valueandtuplehave the same number of entries? If so, isn't it a problem that this is not exposed in the function signature?
To add the answer @Zollerboy1 gave, I would suggest referring back to the review discussion on SE-0393 for more insight into where shape requirements stand and what future directions are.
What does it mean that the tuple is "evaluated"? What would happen if that
tempTuplestep was not there?
You could say that this proposal is offering two ways to think about what it means to use an abstract tuple value in a pack repetition pattern: one way to think about it is to treat it like an implicit conversion to a value pack, and the other way is described in the part you are referencing which is to consider an automatic step of "unwrapping" the value pack from the tuple. I think that the pseudo code could be made more clear in that example though.
It seems that an important purpose of this is to enable local pack variables, could you provide an example of how this would work?
No, let me clarify what I wrote in this proposal about that: the preceding SE-0393 proposal itself is what specifies that, in order to enable local value pack variables, the value pack must be "wrapped" in a tuple. So that is not an idea introduced in this proposal, nor does this proposal offer new means of local variable storage of value packs. However what this proposal does offer is a way to work with the value pack contained within such a tuple (beyond reassignment to another abstract tuple value, which does not achieve anything with the contents of the value pack). Perhaps this warrants more clear language as well.