I would personally call the SUB_microflow fetching the data before opening the page (the DS microflows would retrieve all data over association, then do the filtering). The ‘containing entity’ can be returned or passed to the submicroflow and as a context object to the page. This way you will ensure that the REST call and creation of objects for the data source is only executed once.
Alternatively, the SUB_ microflow could also check if the record already exists, and only create the record if it not exists yet, but you would still have the REST call twice which causes unnecessary additional load on the system...
You could also try adding an enum in the containing entity like “DataRetrievalStatus” (TODO/RETRIEVING/RETRIEVED). If TODO, call the subflow and set to RETRIEVING, the second microflow would then need a loop/wait until all records are RETRIEVED and then to do the filtering. However, this is not very elegant and might still give you concurrency issues (hence I would fetch necessary data before showing the page)
Note: Disallow concurrent execution would never work, because this would also mean that 2 different users are not allowed to run the microflow simultaneously (as the objects are NPE’s there should never be a conflict between 2 sessions). Using “Disallow concurrent execution” is mostly relevant to prevent duplicate background synchronizations for persistent/global data...