Yes, it was intentional, with the reasoning that only an explicit user action should change his own default role. So, when somebody else revokes something from someone it doesn't change user's personal account preferences. Of course, the role won't longer be automatically enabled, but it will be still remembered as a default.

But this behavior can be changed, so if you want to argue that a role revocation should automatically unset user's default role — please do.

Well, my argument is just that it was counter-intuitive for me; however, my expectations are not always the same as common users', there can be reasonable explanation for either way, and I don't see any particular danger in the current behavior (apart from maybe a mild surprise for a user, when they used to have a role long time ago, then it was dropped and well-forgotten, then an admin re-created and re-granted it, and suddenly additional permissions appear by default. But it doesn't sound scary.) So I don't insist on changing it, only on updating documentation.

It does seem a bit counter-intuitive, especially when it's the same user that set the role as default doing the dropping or revoking. I can picture a situation where a user is surprised by a recreated role being default, but the reverse shouldn't really be surprising. Anyway, it's relatively trivial, and the current behaviour is now documented.