1. Will likely be tied to the attribute mapping for LDAP in the CSA on the Security tab, specifically, if the changes in LDAP are not correctly advancing/updating the attribute mapped for Modify Time Stamp, then the Clarity LDAP queries on sync will not see those changes. Active Directory has multiple timestamp style attributes to choose from, so you'll need to pick the one that matches against all the various types of updates you wish to make.
2. I'll defer this to someone who has faced it before.
3. If you're just using a group member criteria in LDAP then they will have to be removed. If you design a specific Search Filter then you could add an exclusion criteria that only includes active members. Just to confirm, the sync job for new/existing users wouldn't alter those records, you'd have to run the other job to remove obsolete users, but you would still need to accommodate the specific search criteria too.
Just one other thing to consider that I've seen be harder-than-average to realise the cause for, and mostly for the AD admins to be aware of: When adding/removing users from a group it's sometimes only the group record timestamp that is updated and not the individual user's. It has been possible in the past to modify a user that is outside the group criteria for Clarity, run the sync job (which advances the 'last run time' for the job, which marks which changes it will pick up next time), move the user into the group so they now meet the criteria, run the job again, and still the user doesn't appear. In those circumstances, as the AD admin changes the group association for the user, they should also lightly 'touch' the user's individual record in AD to bump the modified timestamp so that Clarity will see it.