Having the API as a separated mod wouldn't be practical for users.
Random guess :
Outdated API would cause problems anyway, i think.
There is pretty old bearded solution to keep interfaces backward compatible. Not as beauty, but quite effective.
class IElectricItem {
void someFunc();
}
class IElectricItem2 extends IElectricItem {
void someFunc(ItemStack itemStack);
}
class IElectricItem3 extends IElectricItem2 {
void someFunc(ItemStack itemStack, ItemStack caller);
}
class IElectricItem4 extends IElectricItem3 {
int someFunc(ItemStack itemStack, ItemStack caller, TileEntity machine, int side, int metadata, ..........);
}So if the API is a separate mod then how would IC2 itself interact with it?
What if the API needs to change to support a feature?
Those other mods just have to add a soft dependency to load later than IC2 if it's installed (after:IC2).
As you may know any mod with outdated API that manage to load before IC2 will break IC2, reason for this is very simple - same classes does not load multiple times in vanilla class loader.
Oh, I thought it was the other way around, that the last loaded Mod overrides the already loaded classes. But if it's like that, then the solution is really as simple as just adding a soft dependancy on the API containing Mod.