Actually, here's a use case.
I have assigned 20 users the ClockwiseDancer role, and I have assigned other 30 users the CounterClockwiseDancer role. Oh shit! Clocks turn that way!! All my assignments are reversed! Well, know what? If I rename ClockwiseDancer to CounterClockwiseDancer and viceversa (of course in 3 steps using an intermediate dummy name), that'll do the trick.
Unlikely, I agree. Impossible? no.
Your use case is amusing...
And it demonstrates what I think - there is no such real world use case and its ridiculous to think that there's any benefit NOT to update the relationship table on any change in the items table (as we've mentioned...). Even if was is such a remote use case - I don't think the RBAM module, being an open source software developed on typically very limited resources, should address all of its clients needs. Heck, not even fully established for-profit companies address all their customer's needs. They address most customers needs (...that would generate them the most profit).
But, again, the design of the tables on the first place is really awkward and I fail to get to the bottom of the designer's mind, or perhaps simply its not a good design... . Also, the design demonstrates, I think, the reason for database normalization. With current design, there's duplication of data between the tables - the 'names' of the auth items. As such, it requires a rename to be performed on all tables, as we've seen.
On to more practical words - time to test SRABC extension!