After reading this Wiki article A method to remove orphaned ExpectedRuleEntry objects from your environment from Markus, I came with a question: How to avoid orphaned ExpectedRulesEntry (ERE) object at all?

Imagine that you have an declarative provisioning scenario and outbound sync rule for users turned to fire once object is in 'All people set'.
Imagine you delete a user on the FIM portal.
Depending on your MV object deletion rule setup it might happen that if you delete an object (a user, a group or your custom schema object) it will be provisioned back to the portal and you will get another ERE linked to that object.

You may end soon with thousands of orphaned EREs. The only downside for not cleaning your environment from orphaned EREs is longer full sync cycle runs.
It was enough for me to try to avoid such EREs from appearing in the MV.

The general idea is to prohibit users to delete objects on the FIM portal while there're some outbound sync rules linked to them.
This can be done in two ways:
1. have an MPR with authorization workflow that checks for linked sync rules and either denies a request or takes care of EREs and deletes them.
2. do not delete objects on the portal at all but rather disable them so an object will fall out of the set defined by a Transition Out MPR and all linked sync rules will be removed.

Let me explain the second scenario:
User or Group objects are extended to have new attribute 'status' which is set to true by default in RCDC form or during initial provisioning from MV to FIM portal.
There are two sets: All Active People and All Active Groups created to include only objects with a status=true.
There're 'Transition In' MPRs that watch for objects to appear in 'All Active People' or 'All Active Groups' sets.
Once object is in one of these sets a workflow is started to add an outbound sync rule.
Pretty regular scenario.

But now instead of deleting a user or group on the portal think of the following: do I really need this object to be deleted right now? So many times you need your object back because of many reasons: wrong person's surname in the request to delete a user, wrong date, local ACLs assigned to a group, user's manager forgot to renew an account to contractor and so on...
Ask yourself: whether its enough to disable or expire an account? It might be better to wait for a week or two and delete an account later.

So you're teaching your users not to click 'Delete' button but rather uncheck 'Enabled' checkbox as you configured a Transition Out MPR to remove outbound sync rule for disabled users and groups.

The last step is to create a set with all disabled users or groups and have a time stamp with a date object was disabled. This will allow you to start a workflow when object will enter 'To be deleted' set with another Transition In MPR.

And if you stage an object to delete in your connected MA it might be useful to check 'Do not recall attributes...' so all information about deleted object will remain in MV for your disabled object until it will be deleted. 

More ideas can be found in this thread: Idea to automate the clean-up of orphaned ERE