One issue that just occurred to me is that we want different families of mixin functions to have access to different mix objects, so that one family doesn't have access to mixin functions from another family (since they're private and the constructor must decide what private data shares with the mixin functions). So different mix object could be created for different families based on the reference's base value (by reference I mean the reference that is used to specify the mixin function).
mixin obj, mixinModule.func1;
mixin obj, mixinModule.func2;
mixin obj, func3;
Here func1 and func2 will use the same mix object and func3 will have another mix object.
Another solution would be, since normally mixin functions are imported from other modules, to have the source module of the mixin function as the grouping key for the mixin functions, even if the base value of the reference is an environment record (like in func3's case). If the mixin functions belong to the current module it's fine for them to share the private state.