How container network interface creations work when starting after connecting to multiple networks in stopped state

Hi,
In the process of proposing a PR for https://github.com/moby/moby/issues/20179#issuecomment-550403842 , thus bridging the gap between docker-compose’s network priority feature and libnetwork’s ordered array for sb.endpoints, could you give me some hints on what is lacking on docker’s side to make network priorities functional in docker-compose ?

If i got it well, the docker-compose part is ok : calls to the network_connect API are correctly ordered.
Because I didn’t have time to dig into the docker-py and moby parts of this, today I can just confirm that those priorities are ignored upon container start : https://gist.github.com/jfellus/cfee9efc1e8e1baf9d15314f16a46eca

Networks and containers get connected in the right order, but then when we up/down the said docker-compose project, container get their interfaces created in the lexical order of their network name which is, say, arbitrary…

What I don’t have time to really understand is where this particular decision is made when starting a stopped container that have been connected in a particular order to various networks in a stopped state. Is there any hope to easily code a PR to make the priority settings pass through docker-py, get registered as libnetwork endpoint confs and container interfaces be created in the defined order ?

Thanks !