Im noticing some of your mods blocks/ items are registered in the PreInt phase
if I press r on them it doesn't show the recipe in nei http://pastebin.com/UHGcWZxH

Latest rail craft for 1.7.10
Mod list: http://pastebin.com/ss7RbZ2k

Forge 1614 mc 1.7.10
Java 8 update 91
Mac os x 10.11.4

This isn't likely to change any time soon. It would require completely rewriting how all items are created and getting rid of the lazy initialization scheme.

Could this happen in the future?

@CovertJaguar for 1.9/1.10 you should work with init for recipe loading. I had for example issues when i wanted to make recipe changes with config load (Exchange Redfined Iron with Steel in all IC2C recipes) and because of this bug the config did not work at all...
Also if someone wants to override the API Recipe List he gets all railcraft recipes too and does not have to check for these things either...

And what you could do to make your work easier make a boot class which the items implement. Then you move the same checks to that boot function and these will be called on Init instead of preInit.
(And the items add themselves to the Boot list or you check for the items whatever you like most)

The problem is that it's often the definition of the recipes themselves that causes other items to be defined. Some items are explicitly initialized, but many of the intermediary and raw materials are defined only if something uses them in a recipe.

I suppose I could collect any IRecipe object created during pre-init and then add them all at once to the recipe list during init. I'm not sure I really understand why it matters though. Anything that deals with other mods should always be done in post, I've never heard of an issue with registering things too early.

I'm not one for doing anything unless I understand "why" I'm doing it. And I'm also not one to do anything just because DragonAPI says I should.

Why would anyone want to replace the recipe list? What is this bug that DragonAPI is complaining about? Why can't NEI see the recipes? I'd need an answer to at least one of those questions before I devote time to this.

@CovertJaguar i dont see a reason to why there should be a need to replace a recipe list.
But there is sometimes a reason. Maybe a special Modpack or a mod that wants to change everything
or if there should be features like i did with Crafting using Steel instead of Refined iron
Also: Recipe Map/List should be created in the PreInit but the actual recipes get added during Init

What was the issues with Steel? How did the early register cause you problems?

Wouldn't you just iterate the recipe list in post and replace any instance of Refined Iron with "ingotSteel".
I could see later registration causing issues, but not early.

Well since i am validating in the OreDictionary that Steel is registered (and has also entries) makes it automaticly invalidate it because in preinit when the mod is to early you get no OreDictionary entries unless you register them yourself....
That was a issue i had because recipes got loaded in preinit.

Why are you doing the replacement in Pre-Init though? It's not like there is a forge event for recipe registration. Can't you just scan the list in post? I know it works because I used to do the exact same thing.

You missunderstood here @CovertJaguar.
I change a string variable which is used during recipe creation which has either the oreID: "ingotRefinedIron" or "ingotSteel" when the config is enabled it validates right before the String is used: Hey do we have the "ingotSteel" entries in the OreDictionary. If no ok we reset to "ingotRedefineIron"

        if(ironName.equals("ingotSteel") && OreDictionary.getOres("ingotSteel").size() <= 0)
        {
            ironName = "ingotRefinedIron";
            log.info("Dissabled steel");
        }

When that is in Preinit (which it isnt anymore) then this will automaticly invalidate (the parameter Iron is used in recipes that require RedefineIron)

Can't you also just copy the ore dict entry from one to the other? That way both OreDict entries point at the same items and no recipe modification required?

I'm not really understand how or when you are modifying the recipes.

@CovertJaguar that IronName parameter is used when the Recipes are created.

        if(ironName.equals("ingotSteel") && OreDictionary.getOres("ingotSteel").size() <= 0)
        {
            ironName = "ingotRefinedIron";
            log.info("Dissabled steel");
        }
        advRecipes.addRecipe(Ic2Items.machine, new Object[] {"III", "I I", "III", 'I', ironName });

That is actual code...
Again Iron name gets reseted to ingotRefinedIron when the oredictionary has no ingotSteel itemStack entries.

On preinit that automaticly happens because IC2 (Exp&Classic) is one of the first mods that actually get created. Because of modsorting. And Mods like Railcraft (that register a Steel entry (onPreInit)) are adding it after this recipe Check. So it will autoinvalidated with a wrong assumption because it got used to early....
When this code is fired with Railcraft on PreInit it does not work. if it is fired on Init its fine.

But that's an instance of defining your own recipe during pre-init being too early yes? That doesn't really have anything to do with when Railcraft defines its recipes, only when it defines the Steel item. Which is being done during pre-init like everyone says it should.

Also I've found more info about Rekia's faulty assumptions about recipes:
VazkiiMods/Botania#1817 (comment)

In that comment, he says it breaks because calling OreDictionary.initVanillaEntries() during pre-init will replace random mod recipes incorrectly. But this is a completely bogus assertion as mods aren't supposed to call that function at all anyway and it normally happens before pre-init is even a thing. It is in fact a private method in 1.9. So the "warning" messages from DragonAPI are based on faulty assumptions and improper code use and can be safely ignored as a rule.

Well preinit recipe adding is nothing wrong. I agree but as soon you want to include the oredictionary things that you do not provide (for example my steel recipe change in the config) you have to go to init.
Also it makes it way easier to detect which recipes actually got added by a mod so you do not have to go to onConstruct Event to detect the recipe amount before preinit...

I am just suggestion that to you because its just in case a safer way and does not mess with mods or other stuff who want to add detection to some things or want to do things special...

Makes sense. I do register some recipes in init/post for reasons like this.

I still don't understand what the issue with NEI is though. I can't imagine why it wouldn't be able to find recipes registered in pre-init.

maybe someone tracks & delete them?

Basically the items mentioned can't have r key used to show them via nei.

I've registered items recipes in preinit before and NEI still works fine with it, so it definatelly sounds like another mod is messing with things.

They were vanilla machines (crafting and smeltinn) but I don't see why mod added ones would be different