I was under the assumption that the ``reader`` role wouldn't be specific to the actions of either operators or regular end users. I thought the intention was to leverage the scope of the assignment to answer that question for us.
For example:
Let's assume Sarah is granted the reader role on the system (``openstack role add --user sarah --system all reader``). In theory, she has the ability to list system-specific resources, like endpoints, services, domains, or compute hosts. She can perform audits on the deployment infrastructure. If Chris has the reader role on a project (``openstack role add --user chris --project foobar reader``), he should theoretically have the ability to list instances and volumes within the project. Even though Chris has the reader role, he doesn't have the ability to list system-specific resources, because he doesn't have the system role assignment Sarah has.
We can expand the example to include domain support, too. If Jane has a reader role on a domain (``openstack role add --user jane --domain baz reader``), she theoretically has the ability to view things owned by that domain, like users, groups, or projects whose domain ID is ``baz``.
The same role is used in all three cases, but the target in each user's role assignment is important, too. This might be easier to see in practice between system [0], domain] [1], and project [2] readers all using the ``reader`` role. In my opinion, this gives us more bang for our buck as far as role definitions are concerned. We aren't worried about defining system-reader, domain-reader, and project-reader roles. Additionally, I cringe a little bit thinking about the custom policy required for those cases and the confusion operators might have when Jane gets the project-reader role assignment on a domain.