Hi @rgooler,
The following paragraphs in the documentation above moving between modules discuss this current restriction:
The multi-module refactoring situation is unusual in that it violates the typical rule that a parent module sees its child module as a “closed box”, unaware of exactly which resources are declared inside it. This compromise assumes that all three of these modules are maintained by the same people and distributed together in a single module package.
To reduce coupling between separately-packaged modules, Terraform only allows declarations of moves between modules in the same package. In other words, Terraform would not have allowed moving into module.x above if the source address of that call had not been a local path.
In other words, declaring that something moved into a child module declared elsewhere would impose a compatibility constraint on that other module without it being recorded in that module, and thus maintainers of that module would need to preserve compatibility without necessarily knowing that there’s something to preserve compatibility with.
If you are in control of both modules and in control of making sure that the caller switches to the new version of the called module at the right time for the move to make sense then you can use terraform state mv to tell Terraform to complete the move at that point, just as before.
The requirement for this to be allowed would be to have some new syntax for an external module to declare that it will accept a move from outside to a particular address, so that there is some record in the called module that there is an external interface that other modules may be relying on. That extra feature wasn’t part of the scope of the first phase of this feature, but it’s a likely future enhancement.