The proposal:

• Server Configs are serverside configurations that are synced from the server to the client and are a part of the data pack. These options are reloadable at any time with the data pack. Each mod's server configs would reside in their data packs, something like this: wander:configs/trees.json5 - This would be the configs for the adjusting configs in the trees category for the mod Wander (File format undecided)
• Client Options are clientside options, much like the ones that mojang provides, and belong in the options menus. Fabric API would provide hooks for adding your options in there without breaking other people's options they add. These options do not require a game or server restart, and can happen live at any time. Each mod would have its options file in an options directory on the client. Ex: options/wander.json5 - an example of an option would be to change sky colors in wander biomes (File format undecided)
• Instance Properties are per-instance properties that define registry changes or something that requires a full game restart or a full server restart. Instance Properties are a Fabric Loader function. Each mod would have its properties file in a properties directory in the server and client's directories. Ex: properties/wander.json5 - an example property would be something like choosing not to register new blocks and use vanilla logs instead (File format undecided). These options are not synced and are intended to ship with modpacks (as Forge configs are today in Forge).

Why configs and options should be in Fabric API:

• Configs are part of data packs, fabric loader doesn't load resources or anything like that
• Mods adding options buttons willy-nilly would lead to multiple mods putting buttons in the same place and stuff like that. Having this in Fabric API would keep everything organized and not troublesome.

Configs are part of data packs, fabric loader doesn't load resources or anything like that

Data packs are only a 1.13+ construct, and. I think Loader absolutely should be the authority for at the very least parsing configuration files and providing basic load/save facilities, leaving datapack support, synchronization and more high-level path wrapping to the API.

Sure, the parsing and format I guess could be in loader

I’m just finished with my surgery but when I’m ready to program again I’m gonna generify the stuff so you can pass any parent dir instead of FabricLoadee.getInstance().getConfigDirectory() do you can have config in datapacks too

I also feel like config in datapacks shoulsn’t include requires-restart options, for obvious reasons. I’ll sketch a ResourceReloadListener thing for datapack config-loading when I’m ready.

Well my point is that there should be a separate system for instance level properties

you mentioned in the server the concept of using gamerules, but i dunno how well that'd work without a big rework of the gamerule system.

yeah and then you'd have a set of configs that are per world but separate from data packs and it would be a mess

honestly, the best thing we could do would be to just put config files in datapacks and have ResourceReloadListener to apply them.

I think it's important that we keep the terminology among a config, option, and property distinct or else it'll get super confusing for the users. "Why are my configs in 3 different places?"

what would you define each as?

that was the whole first part of this issue

ahh, forgot that.

I've made a bit of abstraction in the PR so that you can choose where to get the config file from. Using this with a ResourceReload Listener will make it so you can search through data packs for a config directory. I'd have to make something special for datapack-searching, though, because not every datapack is gonna have the configs for all mods.