This sounds nice. The only problem is that there are many more changes which you may like to schedule.
What about role assignments? Or deletion of users? Currently you have to do such an automation over Admin API. You would need to go over all groups/user/roles regularly, check for some self-defined attribute and then apply the changes. Of cause this is difficult for user-group assignments, because they don't have attributes. To ease automation, it would be good to have attributes at the relations.

In addition to attributes at relations there could be a SPI and provider implementations which are executed regular processing of entities. Let's just name them "automation". An automation could process entities and delete them based on an "auto_delete" attribute". A deletion automation could process any type of entity (relations as as well as user, groups, roles, etc.) if access to attributes is unified.
Keycloak core would take care of iterating over all entities. The provider implementation could modify the entity and doesn't need to care about the iterating part or the scheduling.

There could be custom automation implementations which don't modify the entity at all, but create a regular report or send a notification if they find a specific state.

The ability to expire a group membership is a nice addition, but I agree with @jbman that this needs to be a more general concept rather than baked directly onto groups. In addition to what was already mentioned, there are also sessions, etc. that needs to expire and be deleted.

At some point we should also consider a separate service that can perform the expiration of entities, rather than have nodes processing requests do this job. For larger deployments it can significantly affect the response time of a given node.

With that in mind I would rather see some general expiration service. It can initially just run as a background job as we do today for other "cleanup" jobs. Could be something like ExpirationServiceSPI, that has the ability to add an expiration on any entity, and perform the cleanup (that can be disable/delete/send an email/etc.).

I agree that it would be good to have a more general concept.
However, I do not understand well what you want in order to do the implemention and I have some concerns.

• Do you want also to have generic table for knowing when each UserGroupMembership/ User/ Group/ Role expired (validThrough field)? This would lead to extra calls in cache/db for retrieve information for each user/ group etc for ui. For example, we want admin user being able to see when a UserGroupMembership expires and being able to change validThrough. I believe that the expired date should be in each table ( in our case in UserGroupMembershipEntity). ability to add an expiration on any entity would be a seperate action from crud actions?
• In our proposal we have a background job that runs once a day in order to remove expired UserGroupMemberships. We could enhance it for other expired entities ( initial entities need to be defined). This background job can call the cleanup method of ExpirationServiceSPI.
• Job is using ClusterAwareScheduledTaskRunner. I agree @stianst with your second paragraph. How this could be implemented in Keycloak? Do we need it now?