The Railcraft .jar includes the API files for Thaumcraft, IC2, CraftGuide, Forestry, and Buildcraft. This causes crashes when another mod tries to access the API without that mod being present. For example, If I have Railcraft and BetterStorage but not Thaumcraft, BetterStorage will attempt to add Thaumcraft Research because it thinks Railcraft is Thaumcraft, thus causing a crash. Removing the API files manually fixes this with no side effects, but manually doing so is a hassle to users. Please remove these API's from your .jar.

This is the failure of the mod using the API. Not of the mod providing the API.

All API usage should always be prefaced by "if(Loader.isModLoader("modid")".

Lacking any documentation of how the API is intended to be used from Azanor, including the files you need is a perfectly valid use. It is also the traditional method of using APIs. If/When Azanor indicates that this is not how the API is meant to be used, then I will make the necessary adaptations. Until then the burden is on the mods that crash when they assume "presence of api == presence of mod".

For example, the Buildcraft API allows mods to communicate whether or not Buildcraft is present, but to do so requires that those mods include the API.

AFAIK using the @API and @Optional annotations would allow you to use the API without shipping it with the mod but I didn't look into the thaumcraft api and I don't know much about modding minecraft.

Since this started on GregTech, and got reported a few times there, Greg answered this to your reply above:
"Ahem, Forge Standards generally disallow direct inclusion of API Files, which are part of the File Structure of the originating Mod itself (unless said Mod states otherwise, or in case of Interfaces). Existence of API means that the Functionality is existing and working properly, not that the Mod is existing. That is what APIs are for, so that you can include the actual Functionality (and not just the Interfaces!) of said Program in your Program too, and unless you add your own fully functioning Thaumcraft alike Research System to the Game you have absolutely no Reason to include the non-Interface APIs for it.

That is more than enough Reason to remove it. Also it potentially breaks Mods if you include copies of their API."

I'd be interesting in someone providing a link to these "Forge Standards". An official link to some collection of standards, not some offhand IRC comment from someone. And no, Minalin's blog doesn't count.

Because prior to the addition of @optional, my method was the standard, and many APIs are still designed to be used that way (including the BC, Railcraft and Forestry APIs). Even the Thaumcraft API predates @optional, so claiming that its required that I use @optional is ludicrous.

I just really don't see what benefit it provides, aside from making your buildscripts simpler. @API is designed to prevent version conflicts, ensuring the latest version is always the one loaded into memory and ignoring any older versions. The only reason @API even exists is to support including APIs in mods, since you don't need @API if everyone used @optional, and you don't need @optional if everyone used @API. So to claim "Forge Standards"....its a bit of stretch since there appears to be two.

Please see #265

Not to mention that IC2 forbids including it's API... which is also done here on RC...

First of all a link to a tweet : https://twitter.com/minecraftcpw/status/459010478803394560
(well the link in the tweet is a little bit broken, but the conversation should point it out)

What if @API gets deprecated in the future? This isn't unlikely, because @optional does the same job. And "I don't change because its working like this the whole time" isn't an argument. Lets face the consequences of a change. You won't be bugged by people which using mods that actually try to use @optional for their API including. Your mod gets a bit smaller (well not that much). And you said it yourself, smaller and cleaner buildscripts.

At last, i don't think BC is @API only, and this should also be true for IC2.