kfortado thank you so much for the feedback. Please find my response below and let's continue conversation.
An indicator that the Plus Package or any other upgrade plugin is not on a licensed domain. As it is, all features and fields of the package are present, but not working, and there's no indicator of this. A simple warning at the top of the admin page would have saved me a lot of grief.
When it is coming to licensing digital goods, it is near to impossible to make it right. The tricky part comes with notifying user about "unlicensed domain". It is very common for customers to have multiple testing and staging domains that do not follow the recognized by AAM naming convention. Some folks have their own deployment pipeline that manually deploys files to a server without registering domain at all. Many time we've considered to display an admin notification about unlicensed domain or even lock add-on's functionality, however, that would disrupt user experience (you can get annoyed about admin notification really fast).
If you have any AAM premium add-on on the unlicensed domain, it still should work just fine. The only complication is that you are not going to be able to upgrade that add-on to the latest release.
If you make user level settings, and then switch the user role, the user's settings won't work, even with the checkbox in place. I had to manually uncheck and check many, many boxes to fix my issue. So the user settings should be reset if the user role is changed. As it is, it's easy to have checkboxes appear, but no restrictions active.
There are many different ways to look into this problem. Your main focus is on user. For others it can be on role, and for somebody else it can be access policy that is attached to any role, user or all users at once.
The user itself, is on the lowest level in the access settings inheritance chain, which means, it overrides any user role or default settings. I have no intension to discourage you from managing access settings your way, however, please consider to avoid managing access setting on the user level if your users change roles that also have different access settings defined.
If that is not possible, in this case you would have to implement a custom code that will reset all user's access settings by hooking into the WordPress core actions add_user_role, remove_user_role and set_user_role. The code is extremely simple and does not take more than couple lines.