Biome Modification API ignores mod biomes added in data pack loaded via ResourceManagerHelper.registerBuiltinResourcePack(Identifier, ModContainer, ResourcePackActivationType.ALWAYS_ENABLED).
Perhaps loading via ResourceManagerHelper doesn't matter.
#1703 (comment)

I am using the latest version for 1.17 - 0.40.0

Which version are you reporting this against?
See: #1571

From a quick look at the code, I don't see what would be different about those biomes.
The biome modification api just processes the biomes in the dynamic registry.
It shouldn't see a difference between them and vanilla, mod or other datapack biomes.

The only difference between the method you used and other datapack biomes is the packs are not automatically enabled.

Maybe you can knockup a simple example that demonstrates the bug?

Off Topic: The method seems to be a bit misnamed since it doesn't just register resource packs, they are also used as datapacks.

Having figured it out, I realized that the problem is in BiomeSelection.foundInOverworld(). This method does not return biomes added by rewriting minecraft/dimension/overworld.json (I am using multi_noise).

OverworldBiomes.addBiomeVariant() works fine. I wrote a small mod for testing.
reproduce-issue-1703.zip

BiomeSelectors.foundInOverworld() has no biomes added via minecraft/dimension/overworld.json, however, selection by category works (selection.getBiome().getCategory() == Biome.Category.DESERT).

BiomeSelectors.foundInOverworld() has no biomes added via minecraft/dimension/overworld.json, however, selection by category works (selection.getBiome().getCategory() == Biome.Category.DESERT).

foundInOverworld does not actually check which biomes generate in the overworld, but which biomes generate with minecraft:vanilla_layered.

foundInOverworld does not actually check which biomes generate in the overworld, but which biomes generate with minecraft:vanilla_layered.

Perhaps a better name for the method would be?
BiomeSelectors::vanillaOverworldBiomes()
To avoid future confusion.

That's not a good name since it also includes modded biomes registered in code. I don't have any other suggestions, though 😕

IMO we should try to make it compatible with custom overworlds.

IMO we should try to make it compatible with custom overworlds.

I don't see how that is possible in general? You want something that does
BiomeSelectors.foundInDimension(RegistryKey<DimensionType>)

The default logic for what biomes are used goes through
chunk region(dimension) -> world (chunkmanager) -> chunk generator -> biome source -> biome
thats a lot to work backwards through.
In principle, any one of these abstractions can override the logic to be something different.
And I don't think most of these exist yet if you are just using the datapack/create new world screen.

This doesn't include other indirections like the BiomeAccessType, which could directly override the actual biomes used rather than where they appear, but it probably wouldn't work properly if you did.

Not sure if the chunk generator is part of the biome selection context, but couldn't you just get the biome source from that, which has a List<Biome> of all biomes it can generate?

Edit: it doesn't have that currently, only fields about the biome itself.

Not sure if the chunk generator is part of the biome selection context, but couldn't you just get the biome source from that, which has a List of all biomes it can generate?

Looking at this at bit more deeply.

The world creation/loading has a GeneratorOptions which has a SimpleRegistry<DimensionOptions>
Each DimensionOptions has a RegistryKey<DimensionType>
and a ChunkGenerator which has a BiomeSource which has a List<Biome>.

Follow that? :-)

So given a generatorOptions and a dimensionType key you can do something like (pseudo code):

GeneratorOptions generatorOptions = ...;
RegistryKey<DimensionType> dimensionKey = ....
DimensionType dimensionType = getDimensionType(dimensionKey);

List<Biome> biomes = generatorOptions.getDimensions().stream()
    .filter(dimensionOption -> dimensionOption.getDimensionType() == dimensionType)
    .flatMap(dimensionOption -> dimensionOption.getChunkGenerator().getBiomeSource().getBiomes().stream()).toList();

There is however a problem. In all 4 cases where RegistryOps.method_36574 (the place where biome modifications are done) is called the generatorOptions are created afterwards.

This would mean moving the biome modifications mixin to after where the generator options are created in 4 different pieces of code.

I am also not sure, if this would break things.
e.g. if the creation of the GeneratorOptions does things that depends upon the biomes already having their modifications applied.
e.g.2 there is some code that "data fixes" the generator options even later

Yes, it would be great to fix this, but I think it's easier not to write dubious code and just rename methods like this:

vanillaOverworldBiomes();
vanillaNetherBiomes();
vanillaTheEndBiomes();

Selection by biome category is still working. I am currently using getCategory() != Biome.Category.THEEND && getCategory() != Biome.Category.NETHER

Yes, it would be great to fix this, but I think it's easier not to write dubious code and just rename methods like this:

vanillaOverworldBiomes();
vanillaNetherBiomes();
vanillaTheEndBiomes();

The problem is that it's not just vanilla biomes, but also mod biomes added with the Biome API.

Maybe it's better not to support overwriting biomes via dimension/overworld.json? Allow adding (and rewriting) biomes only through OverworldBiomes, NetherBiomes, EndBiomes. Multi noise will be standard in 1.18