Continue to refine the 'barbs' example, which broke some new ground.
Implement the continuous parametric transformations from 2020-05-07 in my notes. This will require some new abstractions.
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). Note that one can find the scale factors by taking the length of the first 3 columns of the transform matrix (supposedly).
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?

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.

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.
If you pre multiply a transformation: you are transforming the entire global space. If you post multiply: you are transforming the current local space.