Since pull requests have limited lifetime but there may be a lot of them, it seems safer to create a stack for each pull request branch (in a single pulumi project). then you can just destroy the stack after you have resolved the pull request, and pulumi will clean everything up. if anything goes wrong it won't affect the other stacks.

regardless of whether you use one stack or many, all the state for a stack is kept in the pulumi cloud service, so there is only one source file.

i.e., for an ECS service, stuff like "what stack has the ECS cluster?" is parameterized via config.yaml. However, since we want our developers to be able to actually deploy stuff without a git push, CONTAINER_TAG is an env var that's injected by our CodeBuild (soon to be Jenkins) system. Each env still retains a separate config file, though, and it definitely does cause friction in an env-per-branch world like you describe. It's possible to write a single Pulumi program that allows many app envs, and doing so would be a lot easier than the equivalent Terraform code, but it'd be a bit rough.