Rather than adding a whole new iterator kind, would it make more sense to direct users that need custom variance to the bucket iterator instead?

That wouldn't really work because you would then need to mutably borrow the entire table inside the iterator, alongside the bucket iterator, to make it work, which would then give the same variance as IterMut. The only other option would be to make IterMut normally unsafe and variant, which feels like a worse option because I'd imagine a lot of code is just using IterMut and expecting the right thing to happen.

Also because you might be confusing the raw bucket API with the one for HashTable: it returns indices, not pointers, so, it's impossible to convert them back into references without the original table. And, mutably borrowing the table inside an iterator would make the whole thing invariant again, defeating the purpose of the variant version of the iterator.

I'm not super happy with this API, but I understand why it is necessary to implement hash_map::IterMut. Since this is such an unusual API, I would prefer if the word "variant" was somewhere in the name, to indicate that the unsafety is because of variance. So maybe IterUnsafeVariantMut? I don't mind it being long, we can say in the documentation that it is primarily intended to be used to implement hash_map::IterMut.

I think giving it a longer, wordier name would probably be okay; part of my thought process was that it was better to offer a variant mut iterator over just offering an iterator without any lifetimes (i.e., over pointers), but in hindsight, I don't really know if that's worth it, since a correct use requires adding markers anyway.

So, perhaps we could just convert this into an UnsafeIter which returns *mut T instead and adds no markers at all?

I've decided to adopt this new approach: it still has a lifetime, but only superficially.

Everything should now properly compile. Got a bit lazy testing changes when dependencies were borked, but now they actually do work.