I'm pretty sure you just described the value prop for CloudFoundry.
Seriously though you're talking about another abstraction layer on top of whatever cloud provider(s) you're using. And the issue with such abstraction layers is that to really make them portable you're stuck with the lowest common denominator of features. Such a thing doesn't really play well with the immaturity and velocity of cloud providers - we need and use the latest features from the cloud providers and get stuck waiting for TF providers to add support. And that's just talking control plane - you also need abstraction layers for all your data plane interactions to homogenize those APIs.
Back in the day RightScale tried to do this but they consistently lagged support for AWS feature releases by upwards of 6 months making it a nonstarter (this was back when things like IAM and VPCs were just getting launched and critical features to make them usable were coming fast). CloudFoundry's approach is to provide an API to run everything on top of a compatible hypervisor control plane API - the lowest common denominator.
The abstraction layer with lowest common denominator is the tricky problem that The Next Big Thing will likely need to solve.
Terraform tries to do it but as you mentioned it’s often a frustrating experience because of lagging providers and Terraform itself is a moving target (at least it was 1-2 years ago). This quickly leads to code rot and dependency hell.
I think containers are the right abstraction for packaging, but orchestration wise we’re still trying to figure out the optimal workflow. K8S, TF and Ansible have shown idempotency is an interesting concept to have. Pulumi improves on that by having procedural logic to describe the desired state. And in my eyes The Next Big should build on those ideas while avoiding or fixing the current rot/lag/dependencyhell problems.
Seriously though you're talking about another abstraction layer on top of whatever cloud provider(s) you're using. And the issue with such abstraction layers is that to really make them portable you're stuck with the lowest common denominator of features. Such a thing doesn't really play well with the immaturity and velocity of cloud providers - we need and use the latest features from the cloud providers and get stuck waiting for TF providers to add support. And that's just talking control plane - you also need abstraction layers for all your data plane interactions to homogenize those APIs.
Back in the day RightScale tried to do this but they consistently lagged support for AWS feature releases by upwards of 6 months making it a nonstarter (this was back when things like IAM and VPCs were just getting launched and critical features to make them usable were coming fast). CloudFoundry's approach is to provide an API to run everything on top of a compatible hypervisor control plane API - the lowest common denominator.