Unsure if this was somehow intended, but this no longer works every time (50/50) you are now reliant on the load order of mods falling in your favour.
I can load the same mod up in 1.18.1 and it work perfectly every time.

for reference here's are some code snippets in case I'm doing something wrong.

    public void onInitialize() {
    
       if (FabricLoader.getInstance().isModLoaded("mythicmetals")) {
            MMCompat.registerModItems();
            ResourceManagerHelper.registerBuiltinResourcePack(new Identifier("mmcompat"),
FabricLoader.getInstance().getModContainer(MOD_ID).orElseThrow(), ResourcePackActivationType.ALWAYS_ENABLED);
            LOGGER.info("Mythic Metals detected, registering items for "+ MOD_ID);
        }

folder path showing location of mmcompat for reference

all recipes under this folder are prefixed with

{
  "fabric:load_conditions": [
    {
      "condition": "fabric:all_mods_loaded",
      "values": [
        "mythicmetals"
      ]
    }

previously we used to get console message to show these RP's were correctly loaded last (outside of the ( )'s) this also no longer occurs in 1.18.2

[Render thread/INFO]: Reloading ResourceManager: Default, Fabric Mods (Alloy Forgery, ArrowsPlus, 
Better Azalea, Better End, Better Nether, Bewitchment, Biome Makeover, Blockus, Botania, Chord, 
DragonLoot, Eat All The Eggs, EdenRing, Enriched, Expert_Armor, Expert Weapons and Tools, 
Fabric Tool Attribute API (v1), Gobber2, Hyper Lighting, Incubus Core, LibCapableData, MC Dungeons Weapons, 
More Tags, Minecraft Transit Railway, Mythic Metals, Netherite Plus Reborn, Patchouli, Promenade, Pugh Tools, 
shroomlight_slab, Simple Mango, Spectrum, Tech Reborn, Paradise Lost - The Aether Reborn, TokenableDecoration, 
Tokenable Furnaces, Trinkets, Twigs, The Wild Mod, ValleyCraft, Variant Barrels, Variant Crafting Tables, 
Variant Sticks and Stuff, WilderWorld, Xtra Arrows), minecraft/mmcompat, minecraft/trcompat, 
minecraft/gobcompat, minecraft/vsascompat, minecraft/botaniacompat

gradle.properties

1.18.1
minecraft_version=1.18.1
yarn_mappings=1.18.1+build.22
loader_version=0.12.12
fabric_version=0.46.2+1.18

1.18.2
minecraft_version=1.18.2
yarn_mappings=1.18.2+build.2
loader_version=0.13.3
fabric_version=0.47.10+1.18.2

Unsure if this was somehow intended, but this no longer works every time

Its not clear what you are reporting. i.e. what is "this"? I will guess in the following...

you are now reliant on the load order of mods falling in your favour

The fabric-loader has never supported any kind of mod loading order.
If your mod depended upon some previous lucky happenstance it was already broken.

for reference here's are some code snippets in case I'm doing something wrong.

I don't see anything that depends on loading order.
Except maybe you competing with the order of registration of builtin packs from some other mod?

previously we used to get console message to show these RP's were correctly loaded last (outside of the ( )'s) this also no longer occurs in 1.18.2

Do they not appear at all or are they in the "wrong order"?
Were they even registered, i.e. have you checked your code actually does the registration in 1.18.2?

Some possibly related things to your bug report:

Known issue where fabric (and other mods) breaking loading order: #1671

If you have already created the world, the order is stored in the save data of the world with any new mods "appended" to that.
This means adding new mods later can produce a different order to what you would get with "Create New World" using the same mods from scratch. This is a limitation with how datapacks work in minecraft (unlike resource packs where you can fix such problems by modifying the options.txt).

When I refer to "mods" above it would be more accurate to use the word "datapacks".
Especially since fabric compresses the main mod resources into one datapack while the "builtin" packs referred to in this bug report are separate packs.

Unsure if this was somehow intended, but this no longer works every time

Its not clear what you are reporting. i.e. what is "this"? I will guess in the following...

you are now reliant on the load order of mods falling in your favour

The fabric-loader has never supported any kind of mod loading order. If your mod depended upon some previous lucky happenstance it was already broken.

for reference here's are some code snippets in case I'm doing something wrong.

I don't see anything that depends on loading order. Except maybe you competing with the order of registration of builtin packs from some other mod?

previously we used to get console message to show these RP's were correctly loaded last (outside of the ( )'s) this also no longer occurs in 1.18.2

Do they not appear at all or are they in the "wrong order"? Were they even registered, i.e. have you checked your code actually does the registration in 1.18.2?

Some possibly related things to your bug report:

Known issue where fabric (and other mods) breaking loading order: #1671

If you have already created the world, the order is stored in the save data of the world with any new mods "appended" to that. This means adding new mods later can produce a different order to what you would get with "Create New World" using the same mods from scratch. This is a limitation with how datapacks work in minecraft (unlike resource packs where you can fix such problems by modifying the options.txt).

given your questions, I'm guessing you haven't used this feature or are unaware of how it functions, but i'll entertain them in case.

Its not clear what you are reporting. i.e. what is "this"? I will _guess_ in the following...
this = bundling resourcepacks with a mod, with aims for overriding loaded mods recipes.

The fabric-loader has never supported any kind of mod loading order. If your mod depended upon some previous lucky happenstance it was already broken.
no it didn't, but RP's were always loaded last, see the console loading message, this was not 'lucky' it worked consistently throughout 1.17.1, 1.18, 1.18.1

Do they not appear at all or are they in the "wrong order"? Were they even registered, i.e. have you checked your code actually does the registration in 1.18.2?
They are registered, it works 50% of the time.
No message at all now regarding loaded resourcepacks

If you have already created the world, the order is stored in the save data of the world with any new mods "appended" to that. This means adding new mods later can produce a different order to what you would get with "Create New World" using the same mods from scratch. This is a limitation with how datapacks work in minecraft (unlike resource packs where you can fix such problems by modifying the options.txt).
Not relevant.

in light of the previous report, it may have found a solution of sorts, could just be coincidence.

I had 3 RP's registered, as soon as I added a 4th it would cause issues.
I have now combined them in to 1, and 'so far' all seems good.. further testing to take place.

Could be limitation of this method or could just be MC janky loading skipping things.

I also rolled back to 1.18.1 mappings.. so could be either ;)

given your questions, I'm guessing you haven't used this feature or are unaware of how it functions, but i'll entertain them in case.

I don't think even the person that wrote the code uses the feature? :-)
It is an attempt to allow mods to do what vanilla does, but vanilla only does it for resource packs.
The code works for datapacks as well, but the actual handling of this list of datapacks is very different to resource packs.
My knowledge comes from trying (with limited success) to fix some of the problems. https://github.com/warjort/nepacks

Could be limitation of this method or could just be MC janky loading skipping things.

I haven't looked at the 1.18.2 version of this code but it goes through many layers, with many paths through the code depending upon how the user does things and whether it is a standalone server.

Besides the ordering issue of #1671 for the providers, it later goes into a TreeMap (name->packs) which means things get reordered by an arbitrary name. These then get merged into any existing packs by either prepending or appending based on what ordering option you specify.

e.g. In your case you have minecraft/xxxx > fabric for that abitrary name comparison.

In total these make it very difficult to maintain a deterministic order which gets even worse when packs change dynamically, e.g. due to mod addition, removal or update, or the user manually adding datapacks.

Can you provide your full project?

think i've managed to resolve this.

i was possibly using it incorrectly.
registering numerous resource packs as soon as it hit 4 it fell over, now only registering 1 with load conditions on the sub folders works perfectly fine

Nope..
Still doesn't work, although given its 1.18.2 I'm guessing this wont get fixed now.
Loader 0.14.9
FAPI 0.58.0

I register my resource pack as follows :

FabricLoader.getInstance().getModContainer(MOD_ID).ifPresent(modContainer -> {
            ResourceManagerHelper.registerBuiltinResourcePack(new Identifier(MOD_ID, "eamodcompat"), modContainer, ResourcePackActivationType.ALWAYS_ENABLED);
            });

Resource pack path looks as follows :

this works 100% of the time in 1.19.2
Loader 0.14.9
FAPI 0.60.0

https://github.com/xanthian/expert_armor

If someone wants to PR the fix feel free... this likely won't be fixed by us.

what changed between 1.18.2 and 1.19.2 in regards to this part ?
I can look at a PR if its not too unreasonable.

I have no idea