Saxon

I'm afraid its not going to be that easy. We have some extension functions (for internal use) that reach into net.sf.saxon.s9api (for example, XPathCompiler so we can provide a "is this a valid expression to use in a <xsl:template match="...">?" function), and those don't compile after removing the IKVM references due to:

error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'IKVM.OpenJDK.Core, Version=8.1.5717.0, Culture=neutral, PublicKeyToken=13235d27fcbfff58'.

(that is: IKVM::java.lang.Object, which is the base class for XPathCompiler)

The only downside I see is the one that we have already: Visual Studio will offer IKVM types and namespaces in certain places.

But in the end, we also need the IKVM assemblies in the output directory anyways, and referencing them is the most convinient way to get this done. (Plus, I don't really know how I'd do that in a post-build step when my source folder is technically a NuGet package)

Re (1), yes I think you're right. While simple applications should be able to be written using only the public stable api in the Saxon.Api namespace, more complex applications may well need to use the "escape hatch" methods to dive down into lower-level (and potentially less stable) classes contained in the net.sf.saxon or com.saxonica namespaces, so the NuGet package should list these as references.

Or, as is default for nuspec, just omit them to reference all :) (which makes changes and updates easier, since you don't have to modify it all the time)