As you said, you can code it, or you could script it in a Scriptable Data Protocol Handler, or even investigate whether the facilities in "Data Driven Virtual Services" (introduced in DevTest v8.5) is most appropriate for you (and include "Request Data Manager" DPH to "keep" the arguments you will always match against, discarding/moving any repeating elements if you will be creating response blocks in a DPH). However, what different use cases are you enabling by doing so?
I think the industry figure is that 70% of tests should be negative testing, so by creating dynamic data responses simply for repeating success conditions, all you're doing is streamlining a bit of the remaining 30%.
What I mean is ... DevTest permits any responses, any business logic differences, any delays, any timeouts, any logic errors that you might want to test for. If there are boundary conditions (in your example, there might be a difference if you have 0 repeating blocks, 1 repeating block, 10 repeating blocks, 256 repeating blocks, etc), it is interesting to have these conditions in your response rather than focusing on dynamic responses that don't increase test coverage. So, in this case you would have 4 static responses, which can be created in seconds and enable your boundary testing conditions and so eating into the 70% of negative testing you should be doing, rather than spending any time on creating something dynamic that won't actually add much value.
If you want to create dynamic responses because your QA efforts are being measured on "number of tests executed", and you can successfully run thousands of automated regression tests if you have dynamic responses, testing the same logic in the application each time and improving the perceived value of QA, then there's an organisational problem rather than a technical one.