Capabilities are saved in the database, per user, per site, and they bubble based on the role they are granted. If you use any plugin that modifies editable roles or capabilities in the database, what you’re doing is changing the individual capabilities for every user that gets that role going forward, but not necessarily every user that had that role in the past.
I think the type-specific dynamic roles are a nice addition to the WP permissions layer. No doubt a significant minority of users will continue to find value and convenience in the ability to customize stored role definitions. Once WP moves to disregard the wp_user_roles array, role editing plugins will just be forced to store the rolecaps array externally and apply them through the filters you provide.
I won’t argue the philosophy of how much customization to fence off for safety/liability, but your writeup exaggerates some of the existing hazards. The “existing users unaffected by role edit” scenario only occurs if custom user capabilities were explicitly assigned. Otherwise, under stock code:
Granting a role stores the role name into the user’s usermeta capabilities array. So editing a stored role definition does affect current members of that role (not just future members).
Granting a role does not store a copy of all currently defined rolecaps into the usermeta capabilities array.
