You'll still be doing that with this new spec. It's still just a "how would you like me to run multiple containers" spec, it's not defining the relationships of arbitrary infrastructure and services on arbitrary networks/providers.

What's going to happen is, you (or the dev) will fill this thing out to the best of your ability. Then someone's going to run it in one env; it won't work, but Ops will modify it to make it work. So then you'll commit that as your one Compose file. Then someone will try to run it in a different env, and it won't work; they'll fix it to make it run. Now you have two Compose files to maintain, with 3 different use cases. So to make it easier to manage, you go back to one for dev, and one for each env. All this because the different components could not be defined independently and loosely coupled, because the spec (and tools) don't support that.

I like Compose for what it's designed for: let a dev mock something up locally. But it's going to become a pain in any environment that scales and will need a different solution.