I'm not sure if you came up with a solution, but since Google seems pretty limited on the topic, I wanted to note what my colleagues and I found that appears to have worked.
If you manage your flows with solutions, export that solution. I think you can also export individual flows. Either way, what you are looking for is the flow's .json file. In the solution export you'll need to unzip the folder and go into Workflows > YourWorkflowName.json
Within the .json file, you'll want to find the property for "runtimeConfiguration" within the trigger. There should only be one property in your whole flow for this so just do a 'find' for that. By default there will likely only be one property within the concurrency object called "runs" and it will be set to whatever you have set the slider to via the UI.
Add a comma, and a new property for "maximumWaitingRuns" and the value you desire. In my case, I did 50. I don't know what a good number is but be advised some caution might be needed here on the number you choose.
Here is how it should look:
Save the file, and re-zip your solution back up. A note on this, you'll want to go inside your unzipped folder highlight all the objects in there and zip it with the same name as the one you originally exported. Don't just try to zip the folder or you're solution import will fail without having the .xml files in the zip ROOT.
Re-import your solution. Once that is completed, you can go to the trigger's "peak code" option and you should see your edit in there.
For testing, I used XrmToolBox's Bulk Data Updater to throw 50 records at a time to the parent flow. All succeeded, whereas before it was failing all flows after the child flow had queued up 11 'waiting' runs. Granted it did take awhile to crunch through everything (basically the reason it was hitting 11+ to begin with), so that is why I advise still being cautious about this as you may find yourself getting throttled by Microsoft for having flows running too slowly.
This documentation is what set me on the path to the solution. However just be aware this documentation is actually for Azure Logic Apps, it just happened to be that property we needed was the same.
https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-actions-triggers#change-waiting-runs-limit
