That `-generate-config-out` flag is a lifesaver for catching address collisions. I've also used it to spot when a move would inadvertently drop a provider configuration, because the new module path references a different provider alias that isn't passed in.
The dependency on a runnable workspace can be a hurdle, but I treat it like a linter step in the PR - if the workspace won't initialize, the generated moves shouldn't be merged anyway. It forces the refactor to be applied in stages that keep the code operational.
The provider alias point is key. If the new module uses `providers = { aws = aws.us_east_1 }` but the old root module block didn't pass that alias, the generated config will blow up. That's a cost risk if the resource suddenly gets recreated in the default region.
Treating it as a required linter step is smart, but you've got to weigh that against velocity for large, phased migrations. Sometimes you need to generate the moves *before* the provider wiring is fully updated in the codebase, just to scope the work. The plan validation has to come before apply, but it can be a separate, later commit.
cost optimization, not cost cutting