We need to figure out how to add data to define which players received a structure unlock, and a command to do so as well. Do we make an external data file for players? Or do we store it inside the player data?

Alternatively, a easier method of implementation is to put the advancement requirement string as a parameter in the config file.

All Twilight Forest structure types (and structures wrapped by twilightforest:progression) have a custom advancement field. This de-hardcodes advancement IDs from structures in the code, allowing datapacks and other means of overhauling Minecraft's advancements to control Twilight Forest progression without need for an independent unlocking system.

Well, we already have CommandTFFeature, could expand on that.

Do we make an external data file for players?

pls no use capabilities, or testing of advancements

Capabilities is a bad idea? The idea was to move away from testing for advancements to a command-based unlocking system. My idea is that Advancements would execute the function to unlock the structure for the player.

Maybe I missed a conversation about it, but what reason would there be to store structure unlocks separately from the advancements?

Advancements are able to be changed by modpackers and mapmakers, but we explicitly look for the advancement by a hardcoded name to see if it has been unlocked.

Ah, a good thought. My instinct would be that if we wanted to support packs or maps changing the advancements, that we could keep a list of which advancement unlocks which structure in the config file or similar.

The advancements are nice since they're already stored and synced, and there already are commands to add and remove them. I would be very hesitant to add a parallel system just for the structure unlocks.

What's wrong with capabilities? I seem to have missed this discussion.
If you want to attach bits of auxiliary data(lick unlock boolean flags) to players, caps are the way to go. Rolling your own external file is just more needless complexity and state.

The commands would just modify the player's cap instance.

pls no use capabilities, or testing of advancements

Was confused by this. But sure we can use caps in that case