The state management is a primary focus for us right now, and I think that's evident from this release: state management CLI tools as well as the beginning of import (which is primarily dealing with state in this iteration).

> ... it still breaks the second anyone ... bypasses Terraform and touches the world directly, so Terraform simply isn't resilient by design.

This shouldn't be true. If you create a new resource that was never under management by Terraform, then yes, Terraform will ignore it. This is by design so that you can use Terraform to manage infrastructure and use other processes to manage other infrastructure that perhaps isn't quite migrated yet OR doesn't fit Terraform's model for whatever reason.

However, if you change a resource under management or even remove it, Terraform will notice this. It is very resilient to detecting drift.

> I never understood the purpose of the state file.

The purpose is to map your resources to what exists in the world. There must be some way to make a mapping there to be able to do diffing, drift detection, etc.

Some cloud platforms provide interesting ways to work around this (AWS tags are often abused for this) and we actually experimented with that approach early on. Unfortunately, not everything supports tags and there was no way for us to separate what was Terraform managed and what wasn't.

One of the features we actually have planned for Terraform in the future is the ability for it to tell you what IS NOT under Terraform management (by comparing local state to global state). For companies that have everything under management, this will be a great check to find any rogue resources. For companies working on adopting Terraform, this will help find things that still need to be migrated/imported.

So, hopefully our state improvements in 0.7 and in the short term will help sway you. They're definitely a top concern. But I also hope I explained my way through some of the design here!

Thanks for the feedback and we hope to see you in the community soon!