OK, it's a completely standard Trie. I love Tries, they have amazing properties for one-to-many and many-to-many string matching, but there is nothing special about this one.

The principal weakness of Tries is their poor memory locality. Finding a string requires O(string length) pointer chases. This one also jumps through a pointer to Dictionary, then Dictionary's own pointer to its bucket array, and then maybe more pointer chasing if entries are chained. (Dictionary<T>'s source)

Many Trie applications have a single major construction step followed by lots of lookups but minimal or no mutations. It would be worth the effort to figure out how to store an entire node, including its child links, in one contiguous chunk of memory. I doubt it could be done in C# easily but I plan to attempt it in C++. Storing the data payload in the same memory block introduces a new problem of how to represent non-terminal nodes, but I have some ideas on how to get around that. (You can also flatten the whole Trie into one huge block, but that is only useful if you never modify it.)

I also don't like how this Trie stores parent pointers. I haven't found a compelling use for them in any Trie-using program I've written. An algorithm that needs to follow the parent pointer should already know its value because it just traversed through it.

Not to hate. I recently started using Tries a lot after not caring about string processing at all for years. Even a standard textbook Trie is incredibly useful. I guess I was hoping to see some clever tricks that would give me ideas for my own Trie implementation.