This “pattern” is very common. One or more rows are used as input for a request that generates one or more output rows per row of input. In my case, the most common instances are with the HTTP module and with the various SQL modules. Without a merge afterwards, the input “parameters” and any linkage to upstream modules is lost.
The idea is:
Create a built in “container” for this type of pattern so that faster and easier to implement and visually easier to understand.
The container has one input and one output. Inside the container is a “space” for a module that will process the input and generate 0 to many rows of output for each row of input. There is one row of container output for each row of module output, but the input data that generated that row is automatically merged in, and just as importantly the upstream linkage is not lost, so downstream modules can sensibly refer to upstream modules when needed.
Also importantly, in cases where the module can create more than one output row per input row (more common with SQL than with HTTP), it’s nearly impossible to merge them back together unless you artificially create a marge key first, which is usually some kind of hack. If the “container” can keep track internally of which output rows go with which input row, that would make the whole thing a lot cleaner and easier to understand.
My use case:
In my flows I almost always need to use both the input and the output of HTTP and SQL Modules later in the flow.
I think it would be beneficial to add this because:
When I was a new N8N user it took me months to figure out this pattern. And it still makes my workflows look ugly. 
And I’m still not confident that it keeps the upstream linkage(s). I think having this as a built-in would make N8N much easier for new people to understand, and cleaner for experienced builders to use.
Any resources to support this?
Just my imagination.
Are you willing to work on this?
Nobody wants me writing code that someone else will use in production.
Lee