Make a series of guidelines for exactly how to order transformations so that I'm actually constructing things to be correct instead of just throwing shit at the wall. See my "Composing Transformations" link in log.org.
My "Barbs" example revealed another pesky limitation: a parent vertex cannot refer to a parent vertex of the parent itself. This came up because I had a rule inheriting 4 vertices (one side of a cube), and creating 4 new vertices (the opposite side of a cube). I wanted its child rules to be able to create faces that had 2 vertices of the parent and 2 vertices that the parent inherited (basically grandparent vertices) - think of one of the remaining 4 sides of the cube. I have no way to do this and no easy workarounds I can see, given that the rule does not have access to the exact vertex positions (so just making new vertices that are 'close' and connecting them isn't an option).
Adaptive subdivision - which means having to generalize past some vmap stuff.
Try some non-deterministic examples.
Get identical or near-identical meshes to ramhorn_branch from Python. (Should just be a matter of tweaking parameters.)
Look at performance.
- Start at to_mesh_iter(). The cost of small appends/connects seems to be killing performance.
- connect() is a big performance hot-spot: 85% of total time in one test, around 51% in extend(), 33% in clone(). It seems like I should be able to share geometry with the Rc (like noted above), defer copying until actually needed, and pre-allocate the vector to its size (which should be easy to compute).
See automata_scratch/examples.py and implement some of the tougher examples.
- twisty_torus, spiral_nested_2, & spiral_nested_3 are all that remain. To do them, I need to compose transformations (not in the matrix sense), but I also probably need to produce RuleEvals which always have xf of identity transformation since the Python code does not 'inherit' transforms unless I tell it to.

Important but less critical:

Elegance & succinctness:
- Clean up ramhorn_branch because it's ugly.
- What patterns can I factor out? I do some things regularly, like: the clockwise boundaries, the zigzag connections.
- Declarative macro to shorten this Tag::Parent, Tag::Body nonsense - and perhaps force to groups of 3? Does this have any value, though, over just making helper functions like p(...) and b(...)?
- I'm near certain a declarative macros can simplify some bigger things like my patterns with closures (e.g. the Y combinator like method for recursive calls).
Docs on modules
Compute global scale factor, and perhaps pass it to a rule (to eventually be used for, perhaps, adaptive subdivision)
swept-isocontour stuff from /mnt/dev/graphics_misc/isosurfaces_2018_2019/spiral*.py. This will probably require that I figure out parametric curves
Make an example that is more discrete-automata, less approximation-of-space-curve.
Catch-alls:
- Grep for all TODOs in code, really.
- Look at everything in README.md in automata_scratch.

If I'm bored:

Fix links in tri_mesh docs that use relative paths & do a PR?
Look in https://www.nalgebra.org/quick_reference/# for "pour obtain". Can I fix this somehow? Looks like a French-ism that made its way in.
Multithread! This looks very task-parallel anywhere that I branch.
Would being able to name a rule node (perhaps conditionally under some compile-time flag) help for debugging?
Use an actual logging framework.
Take a square. Wrap it around to a torus. Now add a twist (about the axis that is normal to the square). This is simple, but it looks pretty cool.
How can I take tangled things like the cinquefoil and produce more 'iterative' versions that still weave around?

Research Areas

When I have an iterated transform, that is basically transforming by M, MM=M^2, MMM=M^3, ..., and it seems to me that I should be able to compute its eigendecomposition and use this to compute fractional powers of the matrix. Couldn't I then determine the continuous function I'm approximating by taking the d/di (M^i)V - i.e. the partial derivative of the result of transforming a vector V with M^i? (See also: https://en.wikipedia.org/wiki/Eigendecomposition_of_a_matrix#Functional_calculus and my 2020-04-20 paper notes. My 2020-04-24 org notes have some things too - this relates to dynamical systems and eigenvalues.) Later note: I have a feeling I was dead wrong about a bunch of this.

Reflections

My old Python version composed rules in the opposite order and I think this made things more complicated. I didn't realize that I did it differently in this code, but it became much easier - particularly, more "inner" transformations are much easier to write because all that matters is that they work properly in the coordinate space they inherit.
Generalizing to space curves moves this away from the "discrete automata" roots, but it still ends up needing the machinery I made for discrete automata.