I've thought of this scenario, and I'm not sure how the capability system would behave in it:

Say mod A defines a handler interface adev.amod.AHandler, and uses it as a capability:

@CapabilityInject(AHandler.class)
public static Capability<IItemHandler> A_HANDLER_CAPABILITY = null;

However, it doesn't publish the capability as part of its API and it doesn't public its source, so I cannot compile against it.

If I, in my apis source set, in the same package define structurally the same interface, and use @CapabilityInject on it, will I get the same instance of the Capability as the one in mod A? How does change when I do/don't ship the AHandler interface with my mod? What if the mod is not present at runtime, will @CapabilityInject still try to reference the missing interface and crash? (I cannot really do any programmatic checks for the presence of the mod since annotations are compile-time constants)

This is a theoretical scenario, any mod that is worth building against will have their capabilities published.

The entire point of the capability system is that it is a soft reference.

Unless you do some dirty reflection hacks specifically on that field to resolve the generic type. Then it wont crash.

As for you faking the cap with your own code. Yes its possible, the JVM doesn't care who wrote the class as long as its structurally the same.

However it is better to talk to the mod author to see if they WANT to allow others to access that cap/feature of their mod.

Right, because type erasure is a thing...

Of course communicating is the preferred way for humans to handle things, I was just making a point.

Thanks for clarifying!