Local variables captured with 0.10.0+ get carried over into mods requiring 0.9.2 compatibility

[TibiNonEst]

A little while ago there was a change made to how local variables are captured with mixin. The minor version was bumped from 0.9.2 to 0.10.0 and a compatibility layer was created to emulate the 0.9.2 local capture behavior to maintain compatibility with mods that relied on it.

The tl;dr of this issue is that, as of the most recent version, while both 0.9.2 and 0.10.0 local variable capture compatibility work fine, when local variables are captured by a mod using 0.10.0 compatibility followed by a mod with 0.9.2 compatibility, the extra variables exposed in the newer version show up in the older version.

This is visible if you load a mod (mod a) depending on some loader version > 0.12.0 that captures local variables from a method, let's use net.minecraft.client.Mouse#updateMouse() as an example, followed by a mod (mod b) that depends on a loader version < 0.12.0 that also tries capture the local variables from updateMouse(). Both of these mods will capture the local variables as expected on their own; if we print the variables to be captured with LocalCapture.PRINT, mod a will report double d, double e, double k, double l, double f, double g, double h, int m while mod b will report double e, double k, double l, int m. This is all to be expected, mod b depends on a version of fabric that requires it to have compatibility with the 0.9.2 local capture behavior. However, if we make sure to load mod a before mod b, mod b will report that it needs to capture all of double d, double e, double k, double l, double f, double g, double h, int m, the same as if it were using 0.10.0 compatibility.

Unfortunately, I do not know how mixin works so I can't give much more technical details than what is written above, the best way I can describe this is to say that the local variables that 0.10.0 compatible mods are exposing get carried over to mods using 0.9.2 compatibility.

Temporarily this can be fixed on the loader side by sorting the load order by mixin compatibility version, however, it would be nice if this behavior could be rectified on mixin's side of things.