`lptabz` is more or less drop-in compatible with both sets & tables (both ordered & unordered) and maybe more explicitly states up front that it is a multiset/multitable which has caused quite a bit of confusion/surprise (What!??! Dups in a hash?! The heck you say! Take it out!! They are now deprecated in `std/tables`).
`lptabz` also has the "sentinel value" optimization which can use < one third the memory space for small integer sets (e.g. 4 bytes per slot vs. 12 or maybe 16 depending on C compiler padding for a uint32 set element). `lptabz` also adds a more "performance guarding" resize protocol using search depth (the actual worst case time) not "filled fraction" (a guess to keep average depth low), and optional Robin Hood reorg for dense memory utilization. I added a few missing API things like `editKey` for the ordered table mode based on [forum thread 6924](https://forum.nim-lang.org/t/6744), saving & loading to files (hacky right now) to optimize [forum thread 5917](https://forum.nim-lang.org/t/5917), `topByVal` based on [forum thread 6604](https://forum.nim-lang.org/t/6604), retrieval by nth in insertion-order per [forum thread 4966](https://forum.nim-lang.org/t/4966#31079). The compact variant also uses my `seqUint` which is a packed array of back-to-back B-bit integers. So, it actually can use ~1/2 the space of the Python index which is just 1,2,4,8 byte integers. (e.g. 17 bits per entry instead of 32 bits for the 2**17 slot case.). There may be a bug or three since I am the only user, but I do use it every day in a couple of non-distributed programs. I don't know about stdlib taking it on. I wouldn't mind, but Araq often says this like ["the stdlib cannot keep up with anything"](https://forum.nim-lang.org/t/6843#42810). My guess is that it might be considered "too featureful". It is definitely more work to "drive" (meaning instantiate mostly) this "omnibus implementation" of what are really 5 different impls in the stdlib (counting `CountTable`).
