I personally think the solution here is to not use terraform. You're trying to bolt this onto something that wasn't well designed for this in the first place. It is going to create so many edge cases that it will be extremely hard for anyone to reason about.
Terraform is quite generic in its nature. At the end of the day it's just a state management tool. We decided to start there as it's the de facto IaC tool, but we are planning on launching a web portal soon and offer other ways to interact with Multy in the future such as an SDK and a CLI tool.
If TF was generic, your tool wouldn't be needed.
My experience with TF is that it is a terrible SMT because they did non-backwards-compatible upgrades to the state file... which made it impossible to redeploy and I had to not only start over with the state file but also recode a bunch of my TF code to support the underlying plugin changes.
Of course this was long ago before it was a final 1.0 version so I'm supposed to give some flex there, but it put me off badly enough that I'd never consider TF a SMT.
At the end of the day, as long as your tool is on top of TF, it will always be a function of the developer to understand all of the idiosyncrasies of not only the different cloud layers, but also the underlying tool. I think you're trying to solve a great problem, but basing it on TF doesn't help.
You asked for feedback... don't use TF.
Or at least use CDKTF which allows you to code around problems, rather than bash your head against TF's awfulness. https://www.terraform.io/cdktf
It is me, or is it weird that this has a hard constructor dependency on Constructs[1], which is pretty much undocumented?
At least in golang, this brings in some other dependencies and golang init() reflect code [2], which then depends on interacting with javascript!? [3]... something smells odd here.
[1] https://github.com/aws/constructs-go
[2] https://github.com/aws/constructs-go/blob/main/constructs/co...