What you're running into is how DABs tracks deployments. A bundle's identity in the workspace is determined by three things: the bundle name, the target name, and the deploying user. When you redeploy with different parameters while keeping those three unchanged, DAB treats it as an update to the existing deployment, not a new one. It matches by resource keys in the state file, not by parameter values.

There are a few ways to get what you want, depending on how dynamic you need this to be.

If you know the instances in advance, the most straightforward approach is what  mentioned: define multiple pipeline resources in your YAML, each with a unique resource key. You can keep them DRY by using custom variables and YAML anchors, or by splitting into separate resource files with include. Something like:

variables:
  schema_a:
    default: schema_alpha  schema_b:
    default: schema_beta
resources:
  pipelines:
    pipeline_a:
      name: my_pipeline_alpha      configuration:
        my_schema: ${var.schema_a}
    pipeline_b:
      name: my_pipeline_beta      configuration:
        my_schema: ${var.schema_b}

Not as elegant as a for-loop, but it works and is fully declarative.

If you want true dynamic instantiation (don't know ahead of time how many pipelines you need), DABs in YAML aren't really built for that. But since the recent Python support for DAB configuration, you can define resources programmatically. You write a Python file that generates resource definitions, and DABs pick them up. That gets you closer to the "class instantiation" pattern you're thinking of loop over a list of configs and emit a pipeline resource for each one.

If you want completely independent deployments from the same template (like, different teams deploying their own version), change the bundle.name per instance. That's what gives each deployment its own state. The uuid approach rvm1975 mentioned works too, but changing the bundle name is more readable and gives you a cleaner workspace layout. You can parameterize it:

bundle:
  name: my_pipeline_${var.instance_name}

variables:
  instance_name:
    description: "Unique name for this pipeline instance"

Then deploy with databricks bundle deploy -t dev --var instance_name=team_a. Each unique bundle name gets its own state file, its own workspace folder, and its own set of resources. No collisions.

One thing to watch out for: allow_duplicate_names: true lets you have multiple pipelines with the same display name, but it doesn't help with DAB state tracking. Two resources with the same key in the same bundle still overwrite each other regardless of that flag.

Hope this helps! If it does, could you please mark it as “Accept as Solution”? That will help other users quickly find the correct fix.