On a tangent, something that would improve TF team work is to simply split state locks into R/W; right now, two read requests (ie. `plan` operations) can't be applied at the same time on a configuration.
It does simplify architecture in a way because everything can be referenced directly in the same projet, but you quickly run ito collaboration issues and runtimes get really long. Use logical states for each discrete piece of a service/module and have those output the needed config/info. Then reference those outputs from other states/modules.
This is the only way I've seen to really scale a TF project effectively. It's not perfect but it's workable even for large teams.
Collaboration should be a non issue, the few people who manage the infrastructure should agree on the work and plan together.
Unlike software code that can be merged later at no risk (a merge conflict at worst), infrastructure does not lend itself to improvising and experimenting on the fly (try to accidentally change your VPC or delete your databases and see how the company goes).
Terraform is something that really highlights when there are multiple people/groups in organization trying to steer the ship in a different direction.
In my opinion ansible/salt do a much better job for often changed resources like instances or services, because it doesn't need to maintain states, it can lookup and match existing resources (mostly by tags). Terraform is better for fixed resources like VPC/networking.
You can it's just non-obvious. What you do is output identifiers in one module and then import that state file as a data resource in another.
Another way is to use a KV store, like AWS SSM Parameter Store or consul. This is useful to link your infra to your CI/CD or even directly to your application
I think separating configurations is important, however it also comes with downsides (which, again, don't detract from the value of separation), making it necessary to use remote states and data sources, in order to reference resources in other configurations.