Hi! I'm the author of a PGF/TikZ-based LaTeX package Forest for drawing (linguistic) trees. I have received several requests to support ConTexT and I'm trying to do that now. Forest uses a lot of \boxes. Actually, the number of boxes used cannot be known in advance, as it depends on the document. Here's why: Forest's main job is to place the nodes of a tree so that they don't overlap and to do that, it needs to first typeset the individual nodes and measure them. The typeset nodes are kept around and later used when typesetting the entire tree. There are three reasons for keeping the typeset nodes, and not typesetting them again as part of the entire tree. First (at least historically): performance. Second: there is no guarantee that running the same code twice will result in the same box. Third: changing this now would break compatibility. The typeset nodes are kept in "local" boxes. They are created using \locbox, which is defined either by plain eTeX format or package elocalloc.sty for LaTeX >2015. (Prior to LaTeX 2015, \locbox was defined in etex.sty.) elocalloc.sty's \locbox is somewhat broken, but still works, mainly because it seems no other package is using local allocation. ;-) Using normal, "global" boxes, created by \newbox, would be bad. If a \newbox was simply executed for each new node, the number of used boxes would remain increased even after Forest was done with a tree, so in a document with lots of big trees, the upper limit of 32000+ could actually be hit. An alternative approach would be to track and reuse boxes which were created by \newbox by are not used anymore. But implementing such a tracking mechanism seems quite complicated, and besides, it would not be perfect: after exiting the TeX group where the tree is drawn, the allocated boxes would persist. (So, from the outside perspective, Forest's box usage in the entire document would equal the box usage of the largest tree.) The approach taken in the implementation of \locbox seems quite appealing in its simplicity: The local boxes (counts etc) are allocated "from the top" (starting at 32767 and going down) and all the \chardefs and allocation register changes are local (i.e. not \global). A bit of care to prevent clashes with global allocation "from the bottom", and that's it. I've studied the allocation mechanism of ConTeXt --- but note that I'm new to ConTeXt! --- and it seems that I'd know how to implement \loc<thing>s using "from the top" approach, but there are two, or rather three, problems. (I took a look at both MKII and MKIV, but the changes seemed mostly cosmetic, so I concentrated on MKIV.) 1. I'm not sure how happy ConTeXt were if I changed the value of \c_syst_max_allocated_register. The name seems to imply it should be constant. 2. Simply decreasing \c_syst_max_allocated_register would while doing a \locbox would also decrease the upper limit for, say, \loccount, as they use the same upper limit, i.e. \c_syst_max_allocated_register. A proper way would be to declare \c_syst_max_allocated_box_register etc. Again, I have no idea how such a change would impact other parts of the system. (Btw, elocalloc.sty's implementation, unlike the plain eTeX one, suffers from precisely this problem.) 3. It seems that, unlike in the messy LaTeX world, ConTeXt people like to do things The Right Way. ;-) As making a change like this in a module is surely not The Right Way, I hope that ConTeXt developers can help me out here, either by implementing the local allocation (I'm happy to assist in any way) or by maybe suggesting an alternative approach. (Btw, if it helps, I guess a MKIV-only solution would be acceptable to most users.) Thanks in advance, Sašo Živanović