bqui great question and I've been getting this type of question already several times in past couple months.
There are several WordPress core constraints as well as user workflows that cause major issues with this type of requirement.
Typically, when we think about access control to a specific resource on a website, we tend to think "yes/no" way. You can or cannot edit this; you can or cannot read this; you can or cannot see this; etc. AAM takes it further and offers 20 different ways to manage access to your content resources.
So when I'm adding new features or customizations to AAM, I'm making sure that they apply to all access options. Your type of requirement, currently, cannot be applied to some of the options and there are the problems:
Core Constraints For LIST option
The LIST option basically filters posts that the current user cannot see. It is relatively easy to hide posts that do not belong to a specific category or user because this information is stored in the database as a one-to-one relation. This way I can construct the database query by joining database tables.
The problem with determining if the current user can see specific post based on the user's role is simply impossible because the information about the user's role is stored as a serialized string in the _usermeta table.
This is the main reason I'm reserved to implement support for your requirement into AAM core.
User Role Charge
Let's assume you have John Doe user who has a Contributor role. He created the post "Hello World" and the next day got promoted to the Editor. Should all the users who are contributors still see the "Hello World" post or not? This is a quite arguably situation?
Obviously, I'm not saying NO to this type of requirement as this is a challenging one and already working on a possible solution with Access Policy. Hopefully this week I'll find time to implement all the necessary changes and prepare access policy for your needs.