I'm not sure if this was resolved some other way in the meantime, but encountered the same issue and the solution above didn't resolve all the problems. I could get more than row of a table to pass through to the workflow using the For Each Value iteration approach, which is progress. But, I wasn't reliably able to get the data across. For some reason, it wouldn't reliably identify the values and run the correct number of times.
I had a form in a business process with a table that users could enter information into, and I needed that user-provided data to be transferred to the workflow via input parameters. I could see from the token tracker that all the rows were being delivered to the workflow.
The next step in the workflow was a Run Rule to take that data and insert it into a Lookup Table. But, the For Each Value activity seemed to insert a random number of rows, with repeats of some rows or skipping others entirely.
I was able to resolve this by eliminating the For Each Value activity. First, I created a hidden text box in the form that contained a formula to fill with the data from the column (=Table.YourColumnName).

I replaced the input parameters for the workflow with the data from that text box (now comma delimited) and redesigned it with a Repeat activity. The condition for the Repeat activity was set to an Assign Token Value that (the token is called "Row Count" in my example), using functions for splitting by commas and the Value Count function, outputted the number of rows from one of the input parameter columns.



The "Start the Iteration token at" needed to be set to "1" because this is being used as the row number, and there is no "0" row.
The inputs into the Run Rule needed to be (1) split using the function and (2) Indexed to the Repeat - Iteration so the data from each column would be placed in the correct row.


This successfully inserted the correct number of rows and indexed correctly. The order of the rows gets mixed up and appears to be random, but that might be something to do with the repeat generating several Run Rule activity invocations and the server loads having capacity for them at different times? Perhaps a delay activity would assist with the order issue, but it isn't a problem for our purposes if the rows aren't in the same submission order.
This seems way too complicated - For Each Value should be able to handle multivalue tokens delivered from input parameters out of the box.
EDIT: I was able to solve the row order issue by adding a column with the submitter's name and the repeat iteration number into the Lookup Table. When pulling the data, I had the rule sort by that column, restoring the submitter's original table order.