What would you like to be added:
Be able to specify multiple targets that where one or more SBOMs are created. Take the following examples for illustrative purposes:

# syft.yaml

inputs:
- type: image
  id: my-image-sbom
  value: docker.io/me/my-image:latest
  format: spdxjson
  
- type: directory
  id: my-source-sbom
  value: ./src
  format: spdx

This would allow for scanning an artifact and source and produce two different sboms, such that in CI invocation would simply be:

# syft.yaml is automatically assumed...
syft
# ...output "my-image-sbom.json" and "my-source-sbom.spdx" files

You could combine the output from multiple cataloging efforts into the same SBOM by using the same id for each input:

# syft.yaml

inputs:
- type: image
  id: my-sbom
  root-package: container
  value: docker.io/me/my-image:latest
  format: spdxjson
  
- type: directory
  root-package: source
  id: my-sbom
  value: ./src

Where the result would be a single my-sbom.json in the spdxjson output. Additionally, anything found in the container will have a relationship tied to a phantom "container" package and anything in the source scanning would have a relationship to a phantom "source" package.

I'm not 100% in love with the proposed format above as it would be easy to abuse when it comes to combining incompatible formats, but it suits for illustrative purposes.

We could surface a small set of this functionality via the CLI by allowing for multiple scan targets:

syft  dir:./  image:docker.io/me/my-image:latest -o spdxjson

Why is this needed:
For more complicated workflows it would be ideal to encode what needs to be cataloged into a description instead of relying on the consumer to orchestrate multiple syft calls with bash.

Additionally there is no way to deal with "multiple" SBOMs with syft, or grouping related items with relationships, which could be a powerful pattern.