Atomic "remove a specific Instance Group member and decrement membership_count" for VPC Instance Groups

Service / Component: VPC Infrastructure Services — Instance GroupsType: Feature request / API enhancementSummaryProvide a single, atomic operation that removes a caller-chosen instance-group membership and decrements the group's membership_count in one call — so the group neither backfills the removed slot nor lets the platform choose a different victim. This is the direct analog of AWS EC2 Auto Scaling's TerminateInstanceInAutoScalingGroup with ShouldDecrementDesiredCapacity=true.Current behaviorScaling an Instance Group down while choosing which member leaves requires two non-atomic API calls:1. DELETE /v1/instance_groups/{id}/memberships/{membership_id} — removes the named member, but because membership_count is unchanged, the group immediately backfills a replacement.2. PATCH /v1/instance_groups/{id} with {"membership_count": N-1} — lowers the target, at which point the platform sheds a member of its own choosing.There is no way to express "remove this member and shrink by one" as one operation. A bare membership_count decrease (step 2 alone) does not let the caller protect a specific member, and in our testing the shed-selection order was not reliably documented (docs indicate oldest-first; we observed newest-first — tracked separately).Requested behaviorAn atomic operation such as one of:- DELETE /v1/instance_groups/{id}/memberships/{membership_id}?decrement_membership_count=true, or- a body flag on the membership delete ({"decrement_membership_count": true}), or- a dedicated action endpoint (e.g. POST /v1/instance_groups/{id}/memberships/{membership_id}/detach with a decrement option),that (a) removes exactly the named membership, (b) decrements membership_count by one, and (c) does not trigger a backfill — as a single, all-or-nothing operation. Behavior should compose with the existing delete_instance_on_membership_delete setting.AWS parityAWS EC2 Auto Scaling has offered TerminateInstanceInAutoScalingGroup(..., ShouldDecrementDesiredCapacity=true) for exactly this purpose since 2011. Customers migrating autoscaling workloads to IBM VPC currently have no equivalent.Workaround and why it is insufficientDelete-then-decrement, gated on the whole group being idle. This works but forbids any scale-down while workloads are running, leaving capacity stranded on a busy group and defeating demand-driven autoscaling in its most valuable case.ImpactWithout this, safe, fine-grained scale-in on IBM VPC Instance Groups is impossible for any workload where individual members are doing non-interruptible work — the caller must either over-provision (never scale down under load) or risk terminating active workloads.