Nowadays all providers are, or can be somewhat easily, just use Upjet to convert a Terraform provider. They walked away from the custom provider maintenance mod

Nowadays all providers are, or can be somewhat easily, just use Upjet to convert a Terraform provider. They walked away from the custom provider maintenance model awhile back due to its lack of scaling potential and loss of network effects from Terraform being the de-jure framework for infrastructure API's I will say that yes, quite a few of the providers are half assed and have bugs. Mostly around how reconciliation works, but also gaps in the provider in how it writes fields due to some Terraform idiosyncracy. I often end up having to ignore various fields in the yaml to prevent drift. But now you can wrap your own without too much effort. HCL itself definitely footguns you into it, it's perverse, because it's intended to be a mere configuration DSL and yet it has since its inception been square pegged into a round hole to do imperative language construct things that it was never designed for. Which is why you get insane practices like "never use an array to iterate over infrastructure in a loop, because removing an element forces a recreation of every resource after that loop because the position of the element in the array shifted to the left". These sort things are completely logical things you would do in a not insane framework (who doesn't use an array to loop over things in a normal software language?), but are a well-known landmine with HCL and Terraform. You could say it was a mistake to use a language like HCL for Terraform and I would agree. It's a half baked idea that became production way too fast. Reminds me of Javascript.