In general, you're probably right about the branchiness of the various trees, but I think acs_objects is a clear exception, and I think we need to make sure and support longer key lengths for that table. Your suggestion of using 7 or 31 length keys seems like a good compromise. You seem to be suggesting that it's important to retain one-byte keys. Have you done any benchmarking to substantiate the need for one-byte keys? Intuitively, it seems likely that wider keys would slow down comparisons when querying, but I wonder how significant the comparison cost is relative to the overall query cost.
One of the things that I really liked about the old text based method was that it was completely generalized, so that you didn't have to worry about the branchiness of the table ahead of time. The m-vgID method would support really deep hierachies, or it would support really wide hierarchies without any pre-implementation requirements to optimize parameters for either case.
The function issue is no big deal, mostly just curiousity on my part, as I wanted to make sure I wasn't missing some subtle detail that could affect performance. I like using the sub-select, because I don't need to know the name of the helper function when I write a query. It's not hard to find out, but it's one less thing to remember when doing new development. Like you said, half a dozen of one, six of the other...
