For "feature complete" I assume they mean that they've implemented all the stable features of the similar container in the standard library, I did not verify this but it seems like a reasonable understanding.

You can reason about its safety/ correctness the same way as the stdlib container types and this will be true for all of (safe) Rust.

The performance considerations have a new dimension for multi-threading though. In single threading you don't need to care whether doing similar operations "at the same time" could affect the performance of what you're doing, but in a concurrent system that's a consideration. Accordingly you would need to benchmark this carefully for your specific usage - just because it's correct doesn't mean it's fast or even acceptable.

Concurrent data structures IMO are those that take advantage of their concurrency and (subtly) alter their behavior for +performance above and beyond what is possible with simple locks.

For example: Count / size() can be imprecise in the realm of concurrency. No need to exactly count the HashTable.

It's impossible to get the size of this table exactly, because the shards are each at best one atomic and no shared lock exists between them. Adding up their individual counts (even if implemented as seq-cst atomics) is incorrect as an atomic is only globally correct within its own atomic operation. And there's no way to atomically gather all the shards sizes without a global lock.

Feature complete would similarly be: all the features you'd expect, except those annoying low performance ones.

It's quite common for concurrent algorithms to only implement a subset of operations. For example forgoing, removal or iteration. It's also common to put limitations on the data structure, such as limiting keys and values to 64-bits. Papaya being feature-complete means that it does not have any of these limitations when compared to std::collections::HashMap.