Regarding the design decision about graph vs sequence: A graph is great to shuffle dependencies. For instance, I might find something that is needed further down the toolchain. By using a graph of dependencies, I can fix that. However, I have never found that something breaks in a GNU/Linux system that can't be fixed with a sequence recompile. Further, even in the simplest system, I'm aware of self-referential nodes, where you have to compile A, then B, then A again before it works correctly (Freetype sticks in my head as one of those, and there are others). The major distributions have also shown the complications of graph-style dependencies. How many times have you used apt or rpm and ended up at a system state you couldn't fix? Then we have tools to fix the tools. Plus, this is for a fixed way to always be able to read/modify/use a particular application over time as well as toolkit documentation, not as a general purpose OS that would be much better served with a popular distro that fits your needs. Off hand, I'm thinking I can get to #e16 and basic server infrastructure for local knowledge management apps with less than 250 steps (source packages). Nonic itself is 77 steps: https://nonic.org/