There's a somewhat major design flaw in the Fabric Biomes API that means that if you change the order that biome mods are loaded in, you can get weird issues with chunk walls and similar. This is much more likely if you have lots of biome mods, since all it takes is one of the mods to get loaded in a different order relative to other mods for bad things to happen.

Adding, updating, or removing any mod could change the mod load order, and thus the load order of biome mods.

There isn't an easy way to fix this without breaking existing worlds, unless we try to figure out the most common load order for biome mods (such as in AoF), and then make a system for deterministically ordering registered biomes that adheres to this order.

I'm noticing this line from the original biome API PR, #1097:

Ordering of modifiers is based around both the given order (first), then alphabetically based on the modifier ID (given to BiomeModifications.create), to guarantee consistent feature ordering regardless of mod-loading order

Have you tested this out or is it a theoretical issue?

That PR you linked is for the Biome Modification API, not the Fabric Biomes API (which is separate). The biome modification API is for modifying existing already-registered biomes, the Fabric Biomes API is for adding biomes to the overworld generator.

I haven't tested this, however after reviewing the implementation, it appears that all registered biomes are added sequentially to a list in WeightedBiomePicker. Thus, the addition of elements to this list is dependent on mod load order.

As far as I'm aware the same issue has existed with Forge for nearly a decade, however, it does not come into play anywhere near as often because most Forge modpacks don't have very many biome mods installed. And most packs have BoP which overrides everything anyways, which bypasses the issue.

However, on Fabric, it's common to have at least two biome mods (Traverse and Terrestria), and it's similarly common to have other mods as well (BYG, Wild Explorer, Sakura Rosea, to name a few). That significantly intensifies the issue.

ahhh, separate, okay. Delicious.

Looking at this, it seems like the best option would be to have it sort once all the initialization is done, maybe with a config option to turn it off to prevent world-breaking.

1.17 might provide a good chance to fix this once and for all if it breaks everyone's worlds anyways.

Also, a related issue, the Biome API lets you register biomes at any time (including, when you are already in a world) so that might be something to patch up as well.

It's possible to reuse the same API but the implementation would definitely have some breaking changes.

@Boundarybreaker The sorting stuff I've added to the modification API was intended to solve this for stuff like features/ores/etc. which would exhibit a very similar problem if the order was non-deterministic.
Simple example: One mod adds a feature that replaces block A in a chunk, another mod adds a feature that places block A. This already makes the result dependent on the order in which these two features are applied.
Same applies to adding biomes I guess, but when I "reactivated" the Biome API this issue is talking about, I just did a simple port-job and didn't actually change the API surface. @coderbot16 is right in that it would most certainly require an API redesign to fix this (in essence, it would need to be more declarative than imperative).