Rather than have your @optional annotations for RF be based on CoFHCore - you should base them off CoFHCore|Energy and then put a soft after dependency on CoFH, EnderIO and a couple of others in your @mod.

Basically there a bunch of mods which repackage the RF API to prevent them needing a hard dependency on CoFHCore so it is entirely possible to be in a modpack with the RF API valid but stripped from all of your machines

The issue with what you're proposing (which is what I started doing when I first moved to @Optional) is that it then requires soft after dependency on every mod that ships the CoFHAPI|Energy package, as a game with some obscure RF mod that loads after Mekanism will crash as the RF classes are not loaded yet when Mekanism loads. The only solutions are to a) live with this crashing by continually adding new soft deps, b) make RF usage depend on some specific mod (in current solution CoFHCore), c) ship the RF API ourselves.

I started with a), then moved to b) when it became untenable to continue to do so. I've been reluctant to move to c) because I've been told by cpw that we categorically should not ship anyone else's apis, ever, but we've later been told by CoFH people (or possibly someone who claimed to have spoken to CoFH people on the issue) that we should ship the RF API, due to it's self-supporting nature. I may decide to do so soon, probably with the upcoming 8.2 update.

While obviously a) is not ideal - as you would need to do it for every mod that ships the package for it to work perfectly, it is superior to b) in that it covers all situations in which b) would work, while also allowing you to cover situations where CoFHCore is not available, EnderIO is really the only one off the top of my head where it would be common to not have CoFHCore in the instance as well, with a minimal bit of extra work "after:XXX;" if any other mods were shown to have this issue.

c) is always a possibility - I am pretty sure I've heard the same from the CoFH guys regarding repackaging the RF API