Totally agreed there. Also condition keys have such a high cognitive load; I can never ever remember the exact spelling of them or whether I need StringEqual or StringIsEqualIfExists or whatever other operator. The documentation has tons of prose about what service-specific keys to expect, but nearly 100% of the time when I'm trying to do something non-trivial with IAM, I end up finding the answer on somebody's blog rather than the documentation.

All of this because the policy language and featureset started off simple enough that it was reasonable to describe policies in json. I sort of wish that they would keep the existing policy stuff as-is but have an escape hatch that let us write lua (or JS or eBPF or something) as "policies", and charge us for the compute time.

I recall that there was at least one case where two similar condition keys that by name should work both, only one was appropriate.

But then I actually blew the stack in IAM processing to the point we couldn't start an AWS sagemaker notebook because IAM died while attaching a network interface to EC2...