This has been discussed many times on the Email list; a review of the treatment of the topic there might also be informative.
A Role is a name with associated responsibilities. That name makes sense only in a Context. A Shape can move and draw in a graphical context; a Cowboy can move, draw and shoot in a Western movie context. Having a role — named however you like — that can draw and shoot does not make it a candidate for reuse in another context.
The Context meaningfully associates objects with its roles so that the objects — which do the work — fit the overall Context goal (use case goal). If a Role spans Context, it lacks the, er, contextualization for it to make sense in a given Context.
From a software engineering perspective, DCI is about readable code. I want to be able to modify a Context locally, understanding its real and latent relationships to other roles in that Context. If a Role exists in multiple Contexts, I can't do that.
See the discussion on “habits” in the Lean Architecture book. They are decontextualized algorithms that don't rise to the criterion of being a use case (system operation). Maybe, in theory, you could reuse a role across multiple habits, but I can't imagine why one would want to do that.
Reuse [of a Role] implies, IMO, that a Role (or at least a Role Method) has a meaning independent of Context. So I challenge you to define the concept independently of the Context it appears in. I'm sure it can be done, but then we probably also have to redefine the semantics of Context.
OOram synthesis lurks in the background here. OOram synthesis explicitly defines how roles can be composed of several roles taken from different role models. (E.g. see figure 3.11 on p. 75 in my OOram book. Rickard: I'll be happy to send you a copy if you haven't already got one) The fundamental point is that I can only combine complete role models, not individual roles.