I believe it is time to remove the FlatTrie from the project in preference of focusing on the RadixTree and the UnsafeTrie. The FlatTrie has some interesting characteristics, but is difficult to improve and will likely always have deficiencies in memory usage and concurrency. Keeping the implementation in the project would be reasonable, but there are a number of types that are only used by the FlatTrie and keeping the codebase focused/lean makes more sense than holding on to an unpromising collection 'just in case'.
My thoughts on the FlatTrie were recorded in #3
I believe it is time to remove the FlatTrie from the project in preference of focusing on the RadixTree and the UnsafeTrie. The FlatTrie has some interesting characteristics, but is difficult to improve and will likely always have deficiencies in memory usage and concurrency. Keeping the implementation in the project would be reasonable, but there are a number of types that are only used by the FlatTrie and keeping the codebase focused/lean makes more sense than holding on to an unpromising collection 'just in case'.