Still unclear how this field will fix the issue? I called the Mgmt API with that property set to true and was able to deploy the same revision to two environments part of the same env group. So how will the routing happen? Will this field make sure that the call goes to the latest deployed environment?

There's an error on the query param for the flag:
has: q.Set("sequencedRollout", serviceAccountName)
should be: q.Set("sequencedRollout", sequencedRollout)

Just testing this out now, the use of sequencedRollout true or false does not prevent the deployment to another env in the same envGroup.

The use of generateDeployChangeReport will indicate: "New deployment will not receive any traffic for basepath /notarget, as this basepath is already claimed by proxy notarget in environment test."

It's up to the user in the UI or the tool invoking the APIs to choose to continue with deployment or not. Even in the UI I can ignore the generateDeployChangeReport and deploy to another env in the same envGroup.

Why is generateDeployChangeReport default false?
Shouldn't it be true to prevent unexpected behavior, like having a proxy deployed to 2 envs in the same envGroup?

Why is generateDeployChangeReport default false? Shouldn't it be true to prevent unexpected behavior, like having a proxy deployed to 2 envs in the same envGroup?

Probably for backward compatibility?

Probably for backward compatibility?

I think that behavior is a bug.