I'd prefer not to do this if it ends up adding more mutable state (like this new checkRoleEnv field). I think there are two separate potential refactoring tasks here:

• Make the roleDeclarations field obsolete using the strategy described in Check roles of mutually recursive types #3860 (comment):

  Speaking of minimising the amount of mutable state we have, it occurred to me that now we are dealing with data binding groups sensibly, we can probably make the roleDeclarations field obsolete by putting role annotations in the same binding group as the data types they refer to, so that the data we need is available at the time we actually need it, rather than having to store them in the environment separately first and pull them back out later.

  Specifically, I'm imagining changing the Sugar.BindingGroups step so that any explicit role declarations end up as part of the same DataBindingGroupDeclaration as the data declarations they describe - I think this should be possible by having edges between the data declaration and the role declaration in both directions in the graph. That way the current addExplicitRoleDeclaration function can become obsolete; if we come across a role declaration which isn't inside a DataBindingGroupDeclaration, we can throw an internal compiler error, because that shouldn't ever happen.

• Store inferred roles in the types field of the Environment during inference. After making the roleDeclarations field obsolete, we should hopefully have access to the data we need regarding declared roles without needing to store them in the environment at all. I don't think it's necessarily a problem to store information we don't yet know for sure to be accurate in the Environment, as long as an error does eventually get thrown if there is a problem. However, on reflection it's less clear to me that this would improve the quality of the code, and the fact that the types field of the Environment contains a bunch of information besides roles might make this a bit awkward. So I'm tempted to not worry about doing this for now.

That is, I'd quite like to do the first at some point (maybe post-0.14.0), but I'm not sure the second is worth doing.

I'm not really that keen on the first refactoring I proposed here now either (see #3881 (comment)) so I think I'm going to close this. I'm sorry for leading you astray!