I went through my mod code (there isn't much there) to see what I was using from PNCR outside of its public API.
Here's what I found...

• Some PNCR recipe types require recipe classes to extend Impl classes.
  This is a problem for adding mod recipes and reading existing recipes. Both scenarios require access to the Impl classes. PneumaticCraftRecipeType defining with Impls:

Non-compliance produces a ClassCastException, in this case when extending PressureChamberRecipe rather than the impl:

Caused by: java.lang.ClassCastException: [...] cannot be cast to me.desht.pneumaticcraft.common.recipes.machine.PressureChamberRecipeImpl
	at me.desht.pneumaticcraft.common.tileentity.TileEntityPressureChamberValve$$Lambda$8886/193290157.accept(Unknown Source) ~[?:?]
        at java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1612) ~[?:1.8.0_51]
	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580) ~[?:1.8.0_51]
	at me.desht.pneumaticcraft.common.tileentity.TileEntityPressureChamberValve.func_73660_a(TileEntityPressureChamberValve.java:145) ~[?:1.16.5-2.13.4-CUSTOM]
        at net.minecraft.world.World.func_217391_K(World.java:491) ~[?:?]

• The PNCR recipe API classes leave getType unimplemented. (minor)
  For example, PressureChamberRecipe does not implement getType, although it's fair to assume all derived classes have the same PressureChamberRecipe recipe type. It would be handy to have the API classes return the recipe types they're tied to, the way the Impl classes do. However, the recipe types are accessible through Minecraft's registry and don't require access to PNCR internals, so this is minor.

• SpawnerCoreStats is internal rather than API.
  No problem with the Spawner Core's Item. Accessing the Core's stats, though, is only practical using the SpawnerCoreStats class, which is not API.

I don't know if anything is practical to change, but I thought I'd take you up on your offer to look into non-API dependencies.

... although it's fair to assume all derived classes have the same [...] recipe type.

This may be a fair assumption, but this...

... have the API classes return the recipe types they're tied to, the way the Impl classes do.

... I realize now won't work. I forgot that the API is (rightly) a standalone thing with its own jar. Even without referencing the common code itself, it seems wrong to tie the API code to the underlying ids. As I mentioned, this is minor since the recipe types are available through Minecraft's registry -- so just disregard this part of the issue.

Yep good suggestions (and you're right about API recipes not including the getType() implementation).

For SpawnerCoreStats, I'm going to add an ISpawnerCoreStats interface to the API rather than promoting the class directly. It'll work like:

ISpawnerCoreStats stats = PneumaticRegistry.getInstance().getItemRegistry().getSpawnerCoreStats(stack);

and provide the necessary methods for querying/updating/saving stats.

Added in 2.13.4 release