That's too bad. If anyone from ODB is reading this thread, please make documentation a higher priority! This is too complex of a product to learn entirely by trial-and-error. In this particular case, my preference would be to use custom JS functions, but after burning several days trying to guess how to make it work, I ended up settling on a custom SQL function instead (and I'm a JS expert).
So far, I've not been able to identify any case where I need to traverse "upwards". To aggregate, all queries still start at the "root". Given that, I only need uni-directional links, but the links need to be "identified" with their time unit value (i.e. if we're at the month level linking to days, I need to know what day the link refers to). That leaves me with a LINKMAP (using the key as the time unit value) or an edge with a property. So even with the proposed but as yet unimplemented uni-direction links, it would still be a heavier solution than the LINKMAP.
Yes, I'm considering some form of pre-allocation, although I'm not yet convinced that this is much better from a performance standpoint. What I do think will help is to pre-allocate space for the LINKMAP in each record when its first created. This comes back to part of my other questions on how much space is actually used on disk for various property types. For example, to make the LINKMAP updates most efficient, I'd want to pre-allocate enough space so the many updates don't each end up moving the record (rather than updating it in place). As it stands, I'm having to determine this through experimentation rather than just reading the docs (which are apparently not just incomplete but also out of date), so I don't have a solution yet.