Other things that don't fit easily into the bugs/clarifications sections
Key lookup issues
Some of this is addressed by the CKA_ID/CKA_LABEL clarification in DocumentClarifications, but at the moment it's far too painful to deal with object lookup, and deletion is even worse (there can be multiple related objects linked to a given object, so saying "Delete the key MyKey" requires complex iterated lookups and probing to find associated public keys, private keys, and certificates to delete.
The way ECC support is currently handled is awful. First, applications need to check a whole slew of CKF_EC_xxx flags to check whether the general type of curve that they want is supported. After that it's basically guesswork, if you want to use (say) the near-universal NIST P256 then after checking all the flags to see whether named Fp curves are supported the only way to tell whether you can actually do P256 is to encode an ASN.1 OID for that curve (!!!), set it as CKA_EC_PARAMS for an object, and then see whether you can perform an operation with the resulting object. As far as I can see the only way to use this is to hope that the more common curves are supported and fail if not.
This area needs a serious cleanup. There should be some means of querying whether standard curves are supported that only requires querying a CKC_xxx ('C' = curve) value, i.e. "is CKC_NIST_P256 supported?") without having to check assorted flags and then performing probing to see whether you can actually use that curve.
In line with this complexity, the bug density in PKCS #11 ECC implementations is higher than usual (see CommonBugs). For example one ECC implementation currently under evaluation claims to do signatures but not signature verification (so you have to take it on faith that if you see a signing key and associated cert, that the cert is actually valid), claims not to do NIST named curves (via the CKF_EC_xxx flags) but comes with sample code that uses them, and returns the catch-all template-inconsistent if you try and use the template given in the PKCS #11 spec.
Potential need for high-volume API
Many functions take session handles, which force serialisation through the session. Scatter/gather and select()-capability would be useful for high-volume use, currently this almost always requires the use of vendor-specific APIs.
Multiple Callers per Process
Some of the stuff needed to make multiple callers in a single process is longer term work: MultipleCallersPerProcess