Then we both have a different perspective at HSMs. I started using HSMs in the old RACAL days and used devices like the good old ERACOM Protect Server Orange. nCipher at that time was nothing more than a SSL accelerator. Today we work a lot with Utimaco HSMs.
PKCS#11 is just one - but not a good - interface to access HSMs. That’s pretty much the reason why most - if not all - HSMs have their own proprietary mechanisms beside PKCS#11, in particular for key management. No HSM implements all of PKCS#11, so when buying a device - in particular a device based on constrained SmartCard technology - you would expect certain limitation. That said, the Nitrokey HSM has a focus on asymmetric crypto operations using RSA and EC. AES was added later to help with certain key management functions that are based on symmetric ciphers (in particular key derivation). It has the characteristic of a HSM, as it supports sophisticated key management mechanisms like key domains or public key authentication using n-of-m schemes. All mechanisms not even remotely supported by PKCS#11.
The native interface of the Nitrokey HSM is not PKCS#11, it’s based on ISO7816-4. OpenSC is a middleware that tries to translate the semantics of PKCS#11 into the ISO7816-4 APDU format. It does that in particular to allow applications to access asymmetric primitives on a SmartCard. It does no try to implement a full PKCS#11 interface.
OpenSC supports a variety of SmartCards and thus indicates mechanisms that might not be available in the card at hand. On the other hand a card might support additional mechanisms not exposed in OpenSC. That is one of the reasons a dedicated PKCS#11 module was developed to implement features that OpenSC - due to it’s layered design - could not support.
I try to understand your frustration, but based on your bold statements in this support forum I tend to believe that your are not looking for a constructive dialog. You may have some points, but I guess they will go unheard.