> and b) exposes an implementation type at the usage site which otherwise could be hidden from client code (e.g. being part of some internal package).

I don't see an issue in that

It is an issue if you want to properly modularize your application or library with clearly separated API and implementation parts. Client code should never invoke the unwrapper directly, so one typically would like to consider it as an internal type. Now client code either references this internal type from the annotation (which is ugly at best or fails in a modularized environment which doen't export internal packages) or you make the unwrapper part of the API of your library which I a library author would prefer to avoid.