Rampant misuse (if it is common) may be a choice forcing argument. This misuse comes from lack of attention to docs for which there is another solution - better/more attention-getting docs Re: surprising features. That could be attempted before removing old functionality.
FWIW, my vague recollection of the logical sense of the github debate was " _Too_ surprising - even 'boldface/`Table` allows dups' would have been insufficient to overcome my (implicitly overstrong) preconceptions." I like to have more faith in people than that. It may be constraining. `critbits` can have no `add`, for example or direct mapped (like array[char]) indices. These feel like special cases, though. Most associative structures like BSTs, skip lists, B-trees allow "inline dups" with similarly distinct space/speed/indirection trade offs an "external dups" like the `seq[V]` solution. So, while one must make psychological guesses about surprise & docs and technological predictions about needs -- I feel/felt both of these did not rise to the "remove long standing functionality" level..Reasonable people could disagree on such judgement calls, I suppose, and maybe learning to not totally rely on the stdlib earlier in one's Nim exposure is not a bad lesson, especially for people coming from Python/scripting domains where such reliance is heavily performance-motivated. In any event, since @exoticisotopic seems new to Nim and seems to be reading & understanding docs (gasp!), and TC brought up removal, and the debate is buried on github, and 1.6 is probably coming up, I thought a "back story" should be told. :-) I also remain curious if @exoticisotopic has another use case in mind or is just carefully reading docs. Please don't be shy! :-) To my own surprise, I found a (performance, as it must be) use case for inline `Table` dups within a few months of the deprecation debate. But I can easily just switch to an `adix/lptabz` dependency which might be faster anyway.
