Both CDK and Pulumi are declarative. The program declares resource desires to an engine, which evaluates a diff and effects change. You cannot instruct the engine what to do, only the desired outcome, which makes it declarative.
You are correct there is an engine - I mistakenly mistook that as criticism of the default state back end, which is not required.
Well yeah, I mentioned that at the end, CDK just produces a declarative cloudformation output.
I think this is a good thing, but I wouldn't say that CDK is declarative, as you don't write declarative code.
You can write literally anything you want in a CDK/Pulumi program.
Depending on how you write it, the outcome could be different every time.
The generated outcome, ie a cloudformation template, is absolutely declarative, but the CDK code is not.
I think this discussion is going on circles because you are both discussing different parts of the problem as if they are the same part.
A system could be said to have a declarative execution model if its input is a description of a desired result and that system then decides for itself what sequence of side-effects to perform to achieve that result. Terraform, CloudFormation, and Pulumi are all declarative by this definition.
However, there's also the question of how you tell the system how to build that data structure in the first place. CloudFormation and Terraform both do so with some form of DSL, with the effect that the source program perhaps more directly corresponds with the data structure it produces. Pulumi instead uses general-purpose languages to generate the data structure, and so the source code that produces it can, if desired, bare very little direct resemblance to the resulting data structure.
The tradeoff here then seems to be more about how far removed the input shape is from the resulting declarative data structure, rather than about "declarative or not". Some folks prefer the input to more directly match the underlying model, while others prefer to intentionally abstract away those details behind a higher level API.
I don't think either is right or wrong... I actually wish these two approaches were complementary inside the same product rather than two companies trying to kick each other in the shins, but that's capitalism for you, I guess.
I've added the "agent SPOF", and "credentials" concern to Pulumi as well, it was an oversight.
Admittedly, my experience with Pulumi is pretty small, but I don't think I'm wrong about it needing a connection the pulumi parent process.
In-fact I opened an issue with Pulumi about problems with this in 2019, and they still haven't closed it.
https://github.com/pulumi/pulumi/issues/3590