The existing set code results in a second, explicit object permission entry even when the inherited entry already exists. I guess this isn't a blocker, it just makes the permissions dirtier.

I think by having a configuration that enforce that a certain object should have a certain permission then that object should be set with explicit permission since the object would not have the permission if it is removed from the parent. So I think the current design is correct.

Though, thinking about it the resource could have another optional parameter (e.g. EvaluateInherithedPermission). If set to $true the inherited permissions could also be evaluated (in some way) and if they have the correct permission the resource assumes it is desired state, but if the inherited permission nor explicit permission exist the resource creates explicit permissions. 🤔