The idea is to remove the insertAutoGeneratedEnumMappings task. This task currently runs stitchs CommandProposeV2FieldNames to generate names from the non-stripped enum variants (at least that's what I think it does). Removing this would require us to map these enum variants ourself. This is not hard, we already do this (I think).
In for example 1.12.2 the task only replaced 16, but detected 2184 "interesting names".
In 12w30e-client it replaced 0 names, and detected 130 "interesting names".

Therefore I think we should just remove that task and simpify the building process.

In the image you can see what would be replaced: the two red arrows to and the one from the insertAutoGeneratedEnumMappings task would be replaced with the green one that directly connects buildFeatherTiny with v2UnmergedFeatherJar.

Note: I plan to open a PR in the future containing that graph.

In terms of code changes:
The task to be removed is:
https://github.com/OrnitheMC/feather-mappings/blob/e28cce1fb4853702bb8e9b68cdc5829a17a1a68e/build.gradle#L1079-L1098
This would require changes in the v2UnmergedFeatherJar task:
https://github.com/OrnitheMC/feather-mappings/blob/e28cce1fb4853702bb8e9b68cdc5829a17a1a68e/build.gradle#L1130-L1140
Mainly the dependsOn would need to change to buildFeatherTiny, and def mappings also needs to use buildFeatherTiny.

This issue is created to discuss how much this would break, since I do not currently know how dependant the mappings are on this feature.

for the future PR: (just using this as notes for later on)

• Remove the insertAutoGeneratedEnumMappings gradle task and instead map these directly; see Remove the insertAutoGeneratedEnumMappings gradle task #142
  I do not yet know the impacts of this, see the issue for this.
  ... maybe there's more that could be cleaned up:
• Why do we use tiny v1 in so many places? We should just switch all to tiny v2 and generate tiny v1 from them.