Seems like Nettle.HashState (corresponding to your CRCState) inherits Nettle.HashInfo (corresponding to CRC), not the other way around.
That can work, although I don't think it's a particularly good idea, precisely because it tends to cause the kind of confusion you're experiencing.
If your static algorithm data is small then you can of course put all of it in the HashState class rather than in the HashInfo (aka Crypto.Hash). That's your implementation freedom. Anyway, a Crypto.Hash must work as a factory and return new unique instances.
I think Crypto.Hash and its descendants preferably shouldn't provide actual hashing services, since that invites users to make the mistake of actually using them, and thereby open up their code for thread concurrency bugs.
As a point in case regarding the confusion here, I note the Nettle.HashInfo.hash() function:
/*! @decl string hash(string data) *! *! Works as a (faster) shortcut for *! @expr{obj->update(data)->digest()@}. *! *! @seealso *! @[HashState()->update()] and @[HashState()->digest()]. */
Given this definition, and assuming "obj" there refers to this_object(), it shouldn't be in the HashInfo since it's not thread safe. The C implementation in Nettle/hash.cmod is also thread unsafe in practice since it does its work in a THREADS_ALLOW. I've fixed that now, at least.