Thank you for the suggestion!

Unfortunately, I believe that this change would break the ability of services in different pods to access each other over the network, which is a very important cage feature that Faraday uses heavily to communicate between front-end services and internal services.

Unfortunately, I believe that this change would break the ability of services in different pods to access each other over the network, which is a very important cage feature that Faraday uses heavily to communicate between front-end services and internal services.

That’s what I mentioned in my PR description, when I said

One effect (drawback?) is that by default a new network will be created for each pod, unless one changes the pod definitions to use a manually-created external network—which is what I did. IMO this is something that should be Cage's responsibility, but I didn't see any code path specific to network creation, so I guess that would be a new feature.

If cage took responsibility for network creation instead of relying on the Docker Compose default behavior, then we could preserve the original behavior that cage provides now without any additional effort on behalf of the user, while still making projects pod-specific.