We put the entries you describe in the users.local file which does not get updated with an ACL push.
We even have an entry in our nsh-install-defaults file that does this at agent install time automagically:
Obviously concatinate what you want to the end of that value.
This is not a bug as much as it is an intermediary step. One of the limitations of the current RBAC model is that it provides no granularity for the RBACAdmins role; if a user is in RBACAdmins, then he/she can manage security on all servers.
In 6.2.0, engineering added a feature whereby RBACAdmins ACLs (except for the main RBACAdmin account) are not distributed to the users file. It is intended that BL security managers instead put their RBACAdmins in the users.local files. This way, it is possible to give users RBAC rights but granularize the servers over which they have security control.
For example, in a two-OS environment (Solaris and Windows), there is often a Solaris RBAC administrator and a Windows RBAC administrator. To employ this system, simply put the Windows RBAC administrator in all the Windows users.local files and the UNIX RBAC administrator in all the UNIX users.local files.
In short, this feature makes managing RBAC accounts slightly less convenient but actually makes it possible to granularize RBAC control to a subset of servers. It's intentional. But it's not the ultimate solution and will ultimately be changed with the next revision or RBAC.
In regards to scripting this out, are you utilizing the blcli add server script? I believe the script currently performs a uname to determine the OS of the server being added. You could take this script one step further and then perform an echo to your users.local file for whichever administrators should be managing that OS through RBAC.