Duplicate resource creation after throttling retry when API response times out

Context

Terraform providers implement retry logic for throttling errors such as AWS Throttling or GCP rateLimitExceeded using the Plugin SDK's resource.Retry helpers. When a CREATE or UPDATE call succeeds on the remote side but the HTTP response is lost due to timeout or network partition, the provider may re-issue the same request.

Problem

If the target resource lacks an idempotency token (e.g., client_token on aws_instance), the retry can create a duplicate resource or apply an update twice. Terraform core does not mandate or verify idempotency-token usage for non-idempotent write operations, and state locking does not protect resources that have not yet been recorded in state.

Constraints

Idempotency support varies by provider and resource; AWS has broader client_token coverage than Azure, GCP, or Kubernetes providers. The Plugin Framework v2 does not introduce core-level retry safety guarantees. No generic Terraform-level workaround exists for resources without native idempotency support.

What determines whether a provider's retry logic re-issues a write request after a response timeout? Which resources across major providers currently lack idempotency-token parameters? Can Terraform core enforce a contract that requires providers to use idempotency tokens for all non-idempotent write operations?