No variable substitution in service names

Description

In 2016 there was a bug-report or feature request with the same title as this one. link At the time it wasn't resolved as the issue seemed to be resolved better by using the compose project name. Since then the include element has been added and I think this might be worth reconsidering.

I ran in to this because I'd like to define a few template services so I wrote the following file (shortened for brevity):

# abstract-service.yaml
services:
  "$APP_NAME":
    build: { args: [ "APP_NAME=${APP_NAME}" ] }

# service.env
APP_NAME=fancy

# docker-compose.yaml
include:
  - path: ./abstract-service.yaml
    env_file: ./service.env

services: { }

Then running docker compose config I'd expect something along these lines:

services:
  fancy:
    build: { args : [ "APP_NAME=fancy" ] }

Obviously this doesn't work and throws a rather predictable validating /.../docker-compose-gist/abstract-service.yaml: services Additional property $APP_NAME is not allowed

Gist for convenience: link

Reproduce the case with abstract-service.yaml, service.env, and docker-compose.yaml by running docker compose config. Review how the include and env_file inputs are processed, then define and verify behavior where the service name becomes fancy and its build argument is APP_NAME=fancy.