maybe SortedSetDocValuesFacetField instead?
There's also another thing that bothers me – nothing prevents the app from creating a SSDVField with hierarchical facets now. So while your tests don't do it, I could easily create such a category (Date/2010/March/21), and then what would happen?
By having SSDVFacetField you can control that by yelling at whoever attempts to do that. For that, taking a CP (see comment below) would make the check easier (if cp.length > 2, it's an error).
But you'd need to provide it with this separator... hmm, or maybe we can use the same sep as FIP.
I think that you should give it a CP, not BytesRef. There is a difference between the separator you give to CP(str, '/') to the one that's defined in FIP. The one that you give to CP (and you can use the vararg constructor to avoid that) just tells CP how to break the string into the path components. For instance, if we removed that ctor, you'd need to call the vararg one by splitting the string yourself.
The one in FIP is used to write the drill-down terms. Currently, following your recent change, it's set to a character that is really not expected to be part of a category string. Therefore I don't worry about it.
As for how the app can set the separator in a server-based environment, there are two options. Define it as part of the index schema – Solr/ES shouldn't care about it, they would just use it to split category strings, but app should know what's a safe separator for it. Another option that we chose to implement, since we work with JSON input, we just defined the facets as an array of strings and then there's no separator worry for the server. App should still be able to construct the array, meaning it should be able to split the category strings based on a 'safe' separator. I don't think we should worry about escaping delimiters. If an app cannot be sure that e.g. '>' is a safe separator, it should escape it itself?