This was indeed a forest issue, but, surprisingly enough, has been present since the very first version of the package. Stefan was simply the first to create such a long, treefull document ... and the switch from v1 to v2 did nothing but push the issue over the edge.
Before explaining what went wrong: I have just posted the fixed version (v2.1.4) to CTAN.
The problem was precisely what Ulrike Fischer mentioned in a comment above. Forest's packing algorithm needs to (temporarily) store some information about coordinates (and pairs of coordinates). Furthermore, given a coordinate (or a pair), it needs to retrieve the information about it fast. The obvious solution is to store the information in a dictionary (associative array), with coordinates being the lookup key, so using TeX's control sequences seemed a perfect idea and I naively did (essentially copy-pasting from my proof-of-concept python implementation):
not realizing that although the definitions are local, the entries will remain in TeX's hash table forever. This approach easily used up a few kilobytes of string pool space per tree!
v2.1.4 reimplements the offending dictionaries by storing all the info in a single toks register, whose contents look like this (shown only for the first of the above problems):
It is easy to search for a specific coordinate in such a structure (although slower than in
% #1=cache toks register, #2=receiving cs, (#3,#4)=point;
% we rely on the fact that the point we're looking up should always be present
(Many packages use such a system, see e.g.\ PGFs
The new system is about 10% slower, but: in Stefan's 800+ page book, where version v2.1.3 exceeded the 6 million char string pool limit, v2.1.4 (and all the other many loaded packages) uses up a meager 2 million. With respect to memory consumption by the packing algorithm, the document length doesn't really matter anymore.
Stefan, thanks for finding this and bearing with me for the past week! (Hint: looking at the packing algorithm anew after these couple of few years, I believe it could also be made much faster!)