Hello and thank you for this issue! The core team regularly reviews new issues and discusses them, but this can take a little time. Please bear with us while we get to your issue. If you're interested, the contribution guide has a section about the decision-making process.

Providers in OpenTofu are globally scoped. In for_each and count, the provider configuration is still tied to that global scope and not to the module instance. We investigated this sort of scenario and decided against it due to intense complexity: https://github.com/opentofu/opentofu/blob/main/rfc/20240513-static-evaluation/module-expansion.md

We however did find a subset of the problem which we believe is easier to solve. Please take a look at #300, which we formalized in an RFC.

This is not exactly what you are looking for, but could potentially be a reasonable solution to your problem. Could you take a look at the linked issue/RFC and let us know what you think?

I've just left a long comment at #300 (comment) about a design hazard with that feature, and I think a variation of that hazard applies to this feature request too.

The variation for this one would be if a shared module contains both a provider "aws" block and a resource "aws_s3_object" "example" block, in this case neither using for_each, and the module were called from the root module like this:

module "has_own_aws_provider_and_resource" {
  # ...
}

Removing that module block effectively removes both the provider "aws" block and the resource "aws_s3_object" "example" block from the configuration at the same time. OpenTofu would notice that the S3 object needs to be deleted to achieve convergence, but now has no provider "aws" block to use to configure that provider.

The root problem both of these ideas have in common is that in today's OpenTofu a provider configuration must outlive all of the resource instances it manages by at least one plan/apply round. Unless that problem is somehow addressed, any feature that effectively forces removing both a resource block and its associated provider block from the configuration at the same time will cause OpenTofu to fail when planning the destroy action.

Hopefully there is a solution to that root problem that would then make both of these feature requests considerably more feasible.

(This is, for what it's worth, also why currently OpenTofu will not allow using for_each in a call to a module that contains a provider block. That's an existing example of something that would cause this trap, if it were allowed. OpenTofu blocks it at creation time to avoid causing someone to create something that they'd later be unable to destroy.)

Hi again!

As I alluded to before, this has some overlap with the problem of dynamic provider expansion: it's largely the same thing just with the expansion happening at the module call level instead of the provider configuration level, giving instances with addresses like like module.foo["a"].provider.bar instead of module.foo.provider.bar["a"].

Therefore this is likely to have a lot of technical work in common with #2155 and so for the moment we're going to consider this issue blocked on that one, just because the provider expansion work already has some design work done and so that one is likely to drive the common work that would later enable this one.

Despite it being marked as blocked we're still interested in community upvotes on the original issue comment to gauge interest in this particular use-case, separately from dynamic provider expansion.

Thanks!