Hi @ohmer,
First I want to note that this topic was something we were using during the beta period for Terraform v0.14 and I ought to have locked it once we released v0.14.0 final, since the design is now largely “locked in” for v1.0 and later under our compatibility promises.
With that said, it sounds like you have some non-default CLI configuration which is overriding Terraform’s default behavior of installing each provider directly from its origin registry and, at the same time, capturing all of the checksums signed by the original publisher to get coverage across all platforms.
In that case, it is indeed necessary to explicitly use terraform providers lock because without direct access to the origin registry Terraform can only record the checksum of the specific packages it downloaded; it has no way to get the other trusted checksums that the provider developer signed.
The terraform providers lock command exists as a compromise so that you can day-to-day use whichever non-default provider installation mechanism you’ve configured, but you can still explicitly ask Terraform to generate a more compehensive set of checksums as part of the process of adding a new provider or upgrading an existing one. Developers should need to do this only if they’re explicitly changing the providers for this configuration, because otherwise the already-stored checksums will remain valid.
I hope the above answers your direct question of what the expected behavior is and, in turn, a little about why Terraform behaves in that way. Since I ought to have locked this topic back at the v0.14 release I’m going to do that now, but if you have other questions about these behaviors then please do feel free to start a new topic about it, and I’m happy to talk some more about how the dependency lock mechanism works and how different custom provider installation options can potentially affect it.