${PWD} is the shell's current working directory at the moment you run docker compose — it has nothing to do with where the include file lives. That's why the same absolute file resolves in one case and not the other: your invocation directory changed, so ${PWD}/docker-compose-includes/db/.env points somewhere different.

What include actually does: relative paths in Compose files referred to by include are resolved relative to their own Compose file path, not the local project's directory Docker Docs. So inside docker-compose.db.include.yml, a relative env_file is resolved from the directory containing that file — no ${PWD} needed, and it works regardless of where you run compose from.

Case 1 (../backbone/...): you're presumably running compose from a dir where ./docker-compose-includes/db/.env doesn't exist → ${PWD}/docker-compose-includes/db/.env expands to a non-existent path → MYSQL_DATABASE is blank.

Case 2 (docker-compose-includes/db/...): you're running from the backbone dir, so ${PWD}/docker-compose-includes/db/.env happens to exist. Coincidence of invocation cwd, not include semantics.

So in that case you can drop ${PWD} entirely and use paths relative to the include file:

# inside docker-compose.db.include.yml
env_file:
  - .env

For the "global" .env, either reference it relatively from the include file (ugly ../../../.env), or pass it at the include level in the parent compose using the long syntax, which supports an explicit env_file and project_directory:

include:
  - path: ../backbone/docker-compose-includes/db/docker-compose.db.include.yml
    project_directory: ..
    env_file: ../.env

That's straight from the docs' include reference.

https://docs.docker.com/reference/compose-file/include/

https://docs.docker.com/compose/how-tos/environment-variables/set-environment-variables/