I've done some testing on this with a reasonably recent shim.

If you have for example dirxml-uACPasswordCantChange in the driver filter as
publisher notify or reset.

Tested two scenarios

1. changing this option alone in AD
2. changing both this option and a read-write option also part of
userAccountControl like dirxml-uACAccountDisable


scenario #1 - the polling notices the object we changed, but decides not to
publish anything back to IDM
scenario #2 - the polling notices the object we changed, and publishes both
changes back to IDM.

To me this looks like a bug, that the shim assumes it can safely filter out
read-only (to IDM) parts of the userAccountControl attribute and only generates
events for parts that are read-write (to IDM).

Anyone else have experiences with this? The point is that some of these
pseudoAttributes can definitely be set by other tools and we should be able to
react to that on the publisher channel.

(also, I know there is a related long standing enhancement request - to add a
way to set dirxml-uACPasswordCantChange via LDAP manipulation of the
ntSecurityDescriptor. Seems to never developed any traction)